Methods and apparatus to determine tire tread depth

ABSTRACT

Methods, Apparatus, and Articles of Manufacture are disclosed for determining a tread depth status of a tire of a vehicle, including an accelerometer interface to access acceleration data from an accelerometer associated with the tire, the acceleration data including first acceleration data indicative of acceleration in a first direction, second acceleration data indicative of acceleration in a second direction, and third acceleration data indicative of acceleration in a third direction, and a data segmenter to segment the first acceleration data into a first data segment, the second acceleration data into a second data segment, and the third acceleration data into a third data segment based on at least one of an acceleration cycle or a common time interval.

FIELD OF THE DISCLOSURE

This disclosure relates generally to vehicle tires and, moreparticularly, to methods and apparatus to determine tire tread depth.

BACKGROUND

Motor vehicles such as automobiles, cars, and trucks include tires fixedon wheels of the vehicles to facilitate traction of the vehicle on asurface. Motor vehicle tires are designed to operate in adverse weatherconditions such as snow and/or rain. As such, treads are disposed on thetires to reduce hydroplaning. Motor vehicle tires are often made ofrelatively soft materials. Thus, the treads of a tire wear down overtime and the tread depth of the tire decreases over time.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example system diagram including an example vehicle, anexample on-board diagnostic module, and an example tread depth modelcontroller that can be implemented in accordance with the teachings ofthis disclosure.

FIG. 2 is an example wheel and an example tire including an example A-Asection line.

FIG. 3 is a cross-section of the example tire of FIG. 2 including anexample accelerometer taken at the A-A section line of FIG. 2.

FIG. 4 is a diagram of example X, Y, and Z direction acceleration dataand corresponding first example X, Y, and Z direction acceleration datasegments segmented based on acceleration cycles.

FIG. 5 is a diagram of the example X, Y, and Z direction accelerationdata of FIG. 4 and corresponding second and third example X, Y, and Zdirection acceleration data segments segmented based on a common timeinterval.

FIG. 6 is a block diagram of the example tread depth model controller ofFIG. 1.

FIG. 7 is a block diagram of an example acceleration data controller.

FIG. 8 is a block diagram of the example on-board diagnostic module ofFIG. 1.

FIG. 9 is a flowchart representative of machine readable instructionswhich may be executed to implement the example tread depth modelcontroller of FIGS. 1 and/or 6, the example acceleration data controllerof FIGS. 6, 7, and/or 8, and/or the example on-board diagnostic moduleof FIGS. 1 and/or 8 for an example training phase and an exampleoperation phase.

FIG. 10 is a flowchart representative of machine readable instructionswhich may be executed to implement the example tread depth modelcontroller of FIGS. 1 and/or 6 and the example acceleration datacontroller of FIGS. 6 and/or 7 to gather and process training data.

FIG. 11 is a flowchart representative of machine readable instructionswhich may be executed to implement the example tread depth modelcontroller of FIGS. 1 and/or 6, the example acceleration data controllerof FIGS. 6, 7, and/or 8, and/or the example on-board diagnostic moduleof FIGS. 1 and/or 8 to gather and process acceleration data for theexample training phase and/or the example operation phase of FIG. 9.

FIG. 12 is a block diagram of an example first processing platformstructured to execute the instructions of a training phase of FIG. 9and/or the instructions of FIGS. 9 and/or 10 to implement the exampletread depth model controller of FIGS. 1 and/or 6 and/or the exampleacceleration data controller of FIGS. 6 and/or 7.

FIG. 13 is a bock diagram of an example second processing platformstructured to execute the instructions of an operation phase of FIG. 9and/or the instructions of FIG. 11 to implement the example accelerationdata controller of FIGS. 7 and/or 8 and/or the example on-boarddiagnostic module of FIGS. 1 and/or 8.

The figures are not to scale. Instead, the thickness of the layers orregions may be enlarged in the drawings. In general, the same referencenumbers will be used throughout the drawing(s) and accompanying writtendescription to refer to the same or like parts. Connection references(e.g., attached, coupled, connected, and joined) are to be construedbroadly and may include intermediate members between a collection ofelements and relative movement between elements unless otherwiseindicated. As such, connection references do not necessarily infer thattwo elements are directly connected and in fixed relation to each other.Stating that any part is in “contact” with another part means that thereis no intermediate part between the two parts.

Descriptors “first,” “second,” “third,” etc. are used herein whenidentifying multiple elements or components which may be referred toseparately. Unless otherwise specified or understood based on theircontext of use, such descriptors are not intended to impute any meaningof priority, physical order or arrangement in a list, or ordering intime but are merely used as labels for referring to multiple elements orcomponents separately for ease of understanding the disclosed examples.In some examples, the descriptor “first” may be used to refer to anelement in the detailed description, while the same element may bereferred to in a claim with a different descriptor such as “second” or“third.” In such instances, it should be understood that suchdescriptors are used merely for ease of referencing multiple elements orcomponents.

SUMMARY

An example apparatus for determining a tread depth status of a tire of avehicle includes an accelerometer interface to access acceleration datafrom an accelerometer associated with the tire, the acceleration dataincluding first acceleration data indicative of acceleration in a firstdirection, second acceleration data indicative of acceleration in asecond direction, and third acceleration data indicative of accelerationin a third direction. The apparatus includes a data segmenter to segmentthe first acceleration data into a first data segment, the secondacceleration data into a second data segment, and the third accelerationdata into a third data segment based on at least one of an accelerationcycle or a common time interval. The apparatus includes a power spectrumgenerator to generate a first power spectrum density associated with thefirst data segment, a second power spectrum density associated with thesecond data segment, and a third power spectrum density associated withthe third data segment. The apparatus includes a data augmenter toaugment the first, second, and third power spectrum densities into afourth power spectrum density. The apparatus includes a statuscontroller to determine the tread depth status based on the fourth powerspectrum density.

An example method for determining a tread depth status of a tire of avehicle includes accessing acceleration data from an accelerometerassociated with the tire, the acceleration data including firstacceleration data indicative of acceleration in a first direction,second acceleration data indicative of acceleration in a seconddirection, and third acceleration data indicative of acceleration in athird direction. The method includes segmenting the first accelerationdata into a first data segment, the second acceleration data into asecond data segment, and the third acceleration data into a third datasegment based on at least one of an acceleration cycle or a common timeinterval. The method includes generating a first statistic associatedwith the first data segment, a second statistic associated with thesecond data segment, and a third statistic value associated with thethird data segment. The method includes augmenting the first statistic,second statistic, and third statistic into a fourth statistic. Themethod includes determining the tread depth status based on the fourthstatistic.

An example electronic control unit (ECU) for determining a tread depthof a tire of a vehicle includes an input interface to accessacceleration data from an accelerometer associated with the tire, theacceleration data including first acceleration data indicative ofacceleration in a first direction, second acceleration data indicativeof acceleration in a second direction, and third acceleration dataindicative of acceleration data in a third direction. The ECU includes adata segmenter to segment at least the first acceleration data into afirst data segment, the second acceleration data into a second datasegment, and the third acceleration data into a third data segment basedon at least one of an acceleration cycle or a common time interval. TheECU includes a power spectrum generator to generate a first powerspectrum density associated with the first data segment, a second powerspectrum density associated with the second data segment, and a thirdpower spectrum density associated with the third data segment. The ECUincludes a data augmenter to augment the first, second, and third powerspectrum densities into a fourth power spectrum density. The ECUincludes a status controller to determine the tread depth based on thefourth power spectrum density.

DETAILED DESCRIPTION

Motor vehicles such as automobiles, cars, and trucks include tirescircumferentially surrounding wheel rims of the vehicles. Tires providetraction between a vehicle's powertrain components (e.g., engine,wheels, axles, etc.) and a surface upon which the vehicle is beingdriven (e.g., a road). In particular, tires are inflated with pneumaticpressure and are in a force-transmitting connection with respectivewheels of the vehicle. Tires can be composed of natural and/or syntheticmaterials such as natural rubber, synthetic rubber, carbon, and steel toprovide for high friction (e.g., a high coefficient of static and/ordynamic friction) between the tires and the road surface. Typically,tires are relatively soft to facilitate this high friction and, thus,wear radially inward (i.e., wear down) over time relative to a centralaxis of the tire.

Vehicle tires such as all-season tires, summer tires, highway tires,winter tires, etc., are designed to operate in a variety of weatherconditions. Weather conditions such as rain and/or snow, etc., can causea layer of water to accumulate on surfaces such as roads. The interfaceof rolling vehicle tires and a surface in these conditions can result ina portion of the depth of the layer of water flowing between contactareas of the tires and the surface.

Vehicle tires include treads (e.g., radially inward grooves relative tothe central axis of the tire) disposed about the tires to divert thelayer of water from the contact areas of the tires and the road surface.The treads can include patterns of grooves extending circumferentially,axially, and at angles therebetween relative to the central axis of thetire. As the tires wear down with use, a tread depth (e.g., a depth ofthe radially inward grooves in the tires) decreases as the radiallyouter surface of the tires wear radially inward. The tread depth is aprimary metric for replacing and/or rotating vehicle tires. For example,when the tread depth of a tire is below a threshold, the tire should beconsidered for being replaced for optimum performance.

Tire tread depth can be inspected manually by, for example, inspectingwear indicator bars etched on the tire by the tire's manufacturer,pressing monetary coins such as a United States quarter dollar coin(e.g., a Quarter) into a tread, and/or using a dedicated tread depthgauge, etc. However, these methods of inspection are often applied onlyinfrequently to a vehicle. Accordingly, it is beneficial for a vehicleoperator to be aware that the tread depths of one or more tires of theirvehicle is near or below the threshold tread depth (e.g., an“unacceptable” tread depth status), or if the tires of the vehicle arein good condition well enough above the threshold tread depth (e.g., an“acceptable” tread depth status). It can be beneficial for a passenger(e.g., an owner, etc.) of an autonomous vehicle to be aware that treaddepths of one or more tires of their vehicle is near or below thethreshold tread depth and needs replacement.

Examples disclosed herein automatically determine (e.g., predict) atread depth status and/or a tread depth of one or more tires of avehicle tire. A tread depth model controller can generate (e.g., train)a tread depth status model to determine and/or predict a tread depthstatus of a vehicle tire in a training phase. The tread depth modelcontroller can conduct a plurality of tests using one or more tires oftest vehicles to collect, access, and/or process training data to trainthe tread depth status model in the training phase.

In some disclosed examples, in the training phase, an accelerometer isfixed to an inner face (e.g., an internal face) of a tire of a testvehicle opposite the treads to record acceleration data (e.g.,acceleration signal(s), accelerometer data, etc.) during operation ofthe vehicle (e.g., rotation of the tires). The accelerometer can recordacceleration data in the X, Y, and Z directions. The tread depth modelcontroller can process the acceleration data. For example, for each testof the plurality of tests, the tread depth model controller can segmentthe X, Y, and Z acceleration data into respective acceleration datasegments. The tread depth model controller can generate a power spectrumdensity, also known as the power spectral density, (e.g., a statistic)for each of the X, Y, and Z acceleration data segments. As used herein,a power spectrum density is a vector representative of the distributionof power according to the frequencies of the data. For example, eachelement of the vector can include the power of a frequency range. Thetread depth model controller can augment the X, Y, and Z power spectrumdensities into an augmented power spectrum density (e.g., an augmentedpower spectrum density matrix and/or vector, a single power spectrumdensity matrix and/or vector, etc.) for each test of the plurality oftests. In other examples disclosed herein, another statistic such asenergy spectral density can be used in place of power spectrum density.

In some disclosed examples, in the training phase, the tread depth modelcontroller can access a measured tread depth (e.g., a measured treaddepth determined by manual inspection with a tread depth gauge) and candetermine an accompanying measured tread depth status (e.g.,“acceptable” or “unacceptable”) for each test. The tread depthcontroller can generate (e.g., train) a tread depth status model basedon the measured tread depth and/or measured tread depth status for eachtest and the respective augmented power spectrum density (e.g., theaugmented power spectrum density matrix and/or vector) for each test. Insome examples, the tread depth status is the target variable (e.g., theclassification, the dependent variable, etc.) of the tread depth statusmodel. In some examples, the tread depth model controller can consideravailable additional data (e.g., vehicle and tire make, model, treaddepth history, vehicle load, vehicle speed, tire pressure, temperatureetc.) for each test. In some examples, the tread depth status model canbe a tread depth model, and the tread depth model controller cangenerate a tread depth model to predict a numerical tread depth of oneor more tires of the vehicle additionally or alternatively to a treaddepth status.

In some disclosed examples, the tread depth model controller can use asupervised Artificial Intelligence (AI) and/or Machine Learning (ML)model such as a Support Vector Machine (SVM), a Neural Network (NN), ora Random Forest (RF) to generate (e.g., train) the tread depth statusmodel. For example, the tread depth mode controller can provide (e.g.,deploy) the generated tread depth status model to an on-board diagnosticmodule of a vehicle (e.g., an Electronic Control Unit (ECU)) todetermine (e.g., predict) the tread depth status of the vehicle duringoperation of the vehicle in an operation phase of the tread depth statusmodel.

In some disclosed examples, in the operation phase, like in the trainingphase, an accelerometer is fixed to an inner face of a tire of thevehicle opposite the treads to record acceleration data during operationof the vehicle. The accelerometer can record acceleration data in the X,Y, and Z directions. The on-board diagnostic module can process theacceleration data. For example, the on-board diagnostic module cansegment the X, Y, and Z acceleration data into respective accelerationdata segments. The on-board diagnostic module can generate a powerspectrum density, also known as the power spectral density, (e.g., astatistic) for each of the X, Y, and Z acceleration data segments. Theon-board diagnostic module can augment the X, Y, and Z power spectrumdensities into an augmented power spectrum density (e.g., an augmentedpower spectrum density matrix and/or vector, a single power spectrumdensity matrix and/or vector, etc.).

In some disclosed examples, in the operation phase, the on-boarddiagnostic module can predict a tread depth status (e.g., “acceptable”or “unacceptable”) of one or more tires of the vehicle based on theaugmented power spectrum density. In some examples, the on-boarddiagnostic module can consider available additional data (e.g., vehicleand tire make, model, tread depth history, vehicle load, vehicle speed,tire pressure, temperature etc.). In some examples, the on-boarddiagnostic module can predict the tread depth (e.g., the numerical treaddepth) of the vehicle with a tread depth model.

In some disclosed examples, the on-board diagnostic module can transmitthe determined tread depth status to a display of the vehicle. Theon-board diagnostic module can transmit the tread depth statusdeterminations, the underlying acceleration data, and/or intermediatedeterminations to the tread depth model controller to regenerate (e.g.,re-train) the tread depth status model. Advantageously, examplesdisclosed herein do not require manual and/or visual inspection of oneor more tires of a vehicle to determine and/or predict the tread depthstatus of the vehicle. However, in some examples, the tread depth of thevehicles is measured, and the measured tread depth is transmitted to thetread depth model controller to contribute to the regeneration (e.g.,retraining) of the tread depth status model.

In some disclosed examples, the tread depth model can be a regressionmodel to make a numerical prediction of the tread depth based on theaugmented power spectrum density. In these examples, the on-boarddiagnostic module can provide the predicted tread depth and/or the treaddepth status associated with the predicted tread depth of one or moretires to the display of the vehicle.

Now turning to the figures. FIG. 1 is an example system diagramincluding an example vehicle 100, an example on-board diagnostic module102 to execute a training phase to generate a tread depth status model,and an example tread depth model controller 104 to execute the operationphase of the tread depth status model that can be implemented inaccordance with the teachings of this disclosure. In the illustratedexample of FIG. 1, the vehicle 100 includes an example Front Left (FL)tire 106 and Front Right (FR) tire 108 positioned on front wheels of afront axle of the vehicle 100. The vehicle 100 also includes an exampleRear Left (RL) tire 110 and Rear Right (RR) tire 112 positioned on rearwheels of a rear axle of the vehicle 100. In other examples, the vehicle100 can have any other number of tires (e.g., a vehicle with two wheelshaving two tires on the front axle and four wheels having four tires onthe rear axle, a vehicle with three or more axles, etc.).

In the examples disclosed herein, the term “radial” refers to thedirection perpendicular to a central axis of a tire (e.g., one of thetires 106-112). The terms “radially inward” and/or “radially inner”,etc., refer to a radial position relatively closer to the central axisof the tire, and the terms “radially outward” and/or “radially outer”,etc., refer to a radial position relatively farther from the centralaxis of the tire. The term “axial” refers to the direction parallel tothe central axis of the tire and/or an axle of a vehicle. The terms“axially inward” and/or “axially inner”, etc., refer to an axialposition relatively closer to the center of the vehicle, and the terms“axially outward” and/or “axially outer”, etc., refer to an axialposition relatively farther away from the center of the vehicle. Theterm “circumferential” refers to a direction along the circumference ofthe tire.

In the illustrated example of FIG. 1, the on-board diagnostic module 102is implemented by an ECU of the vehicle 100. For example, the on-boarddiagnostic module 102 can be implemented by a Body Control Module (BCM).In FIG. 1, the on-board diagnostic module 102 is communicatively coupledto aspects and/or components of the vehicle 100 via an example vehiclebus 114. In FIG. 1, the vehicle bus 114 can be implemented by one ormore wired or wireless connections and/or communications networks. Forexample, the vehicle bus 114 can be implemented by a Controller AreaNetwork (CAN) bus and/or one or more Radio Frequency (RF) modules tocommunicate with one or more wireless accelerometers (e.g., via aBluetooth® interface, via a near field communication (NFC) interface,etc.) positioned inside one or more of the tires 106-112.

In the illustrated example of FIG. 1, the on-board diagnostic module 102can access acceleration data (e.g., accelerometer data) fromaccelerometers positioned inside one or more of the tires 106-112. Forexample, the on-board diagnostic module 102 can process the accelerationdata and can apply the tread depth status model generated by the treaddepth model controller 104 to determine the tread depth status of one ormore of the tires 106-112 of the vehicle 100. The on-board diagnosticmodule 102 can provide a tread depth of the one or more of the tires106-112 to an example vehicle display 115 (e.g., a display 115) of thevehicle 100 via the vehicle bus 114. For example, the display 115 can bean infotainment system, a dashboard warning light, or any other suitabledisplay 115 of the vehicle 100.

In the illustrated example of FIG. 1, the on-board diagnostic module 102is communicatively coupled to the tread depth model controller 104 viaan example network 116. In FIG. 1, the tread depth model controller 104is communicatively coupled to one or more test vehicles. For example,the tread depth model controller 104 can collect and/or accessacceleration data, measured tread depth values, and/or additional datafrom one or more tires of each of the one or more test vehicles. Thetread depth model controller 104 can generate (e.g., train) the treaddepth status model based on the training data for the one or more testvehicles. For example, the tread depth model controller 104 can becommunicatively coupled to the one or more test vehicles via one or morevehicle busses (e.g., analogs of the vehicle bus 114 of the vehicle 100)via any other suitable wired connection, wireless connection, and/orcommunications network to gather the training data.

In some examples, the tread depth model controller 104 can access, viathe network 116, acceleration data, tread depth statuses, and/ormeasured tread depth values, collectively referred to as operation data,concerning the tires 106-112 and/or the vehicle 100. The tread depthmodel controller 104 can regenerate (e.g., re-train) the tread depthstatus model based on the operation data for one or more vehicles. Insome examples, the tread depth model controller 104 can transmit updatedand/or improved tread depth status models to the on-board diagnosticmodule 102 via the network 116. In FIG. 1, the tread depth status modelcan be preloaded (e.g., deployed) on the on-board diagnostic module 102and/or updated (e.g., replaced with an improved tread depth statusmodel) at any suitable frequency.

FIG. 2 is an example tire 200 of an example wheel 202 including anexample A-A section line 204. The tire 200 is representative of any ofthe tires 106-112 of the vehicle 100 (both of FIG. 1) and isrepresentative of any of the tires of the one or more test vehiclescommunicatively coupled to the tread depth model controller 104 (FIG.1). For convenience, the tire 200 is discussed in connection with thevehicle 100. In the view of FIG. 2, the tire 200 includes an examplecontact area 206 at the interface of the tire 200 and a surface uponwhich the vehicle 100 is being driven. In this example, the contact area206 is the portion of the tire 200 that is at the interface of the tire200 and the surface upon which the vehicle 100 is being driven.

In the example of FIG. 2, the contact area 206 is flattened toillustrate a deformation that occurs in the tire 200 when the vehicle100 rests upon the tire 200. The flattening of the contact area 206 maybe overemphasized in order to show the deformation. For example, whenthe tire 200 is rolling clockwise in the orientation of FIG. 2, the tire200 includes a first deflection point 208, wherein the tire 200 beginsto deform (e.g., deflect and/or flatten). Similarly, when the tire 200is rolling clockwise, the tire 200 includes a second deflection point210, wherein the tire 200 moves from a flattened and/or deformed stateback to its undeformed and/or original state. This deformation andsubsequent release occur during each rotation of the tire 200. In someexamples, the first deflection point 208 and the second deflection point210 can be switched based on the direction of revolution of the tire200.

FIG. 3 is a cross-section 300 of the example tire 200 of FIG. 2 takenalong the A-A section line 204 of FIG. 2. In this example, the tire 200is in the deformed state and the outer face of the tire 200 is part ofthe contact area 206. In FIG. 3, the cross-section 300 is shows the tire200 having a homogenous composition depicted by uniform cross-hatching.However, in other examples in accordance with the teachings of thisdisclosure, the tire 200 can include natural and/or synthetic bodyplies, cap plies, belts, belt covers, beads, etc., along with geometricvariations such as one or more recesses, cavities, etc., not shown inFIG. 3.

In the illustrated example of FIG. 3, an example accelerometer 304 isfixed to an example radially inner surface 306 of the tire 200 at ornear the axial center of the tire 200. Accordingly, during operation ofthe vehicle 100, the accelerometer 304 rotates about the central axis ofthe tire 200. In this example, the accelerometer 304 is within aninternal pressurized cavity 308 of the tire 200. For example, theaccelerometer 304 can be a stand-alone accelerometer or integrated aspart of a larger Inertial Measurement Unit (IMU). In the view of FIG. 3(e.g., the cross-section 300), the accelerometer 304 is cut in half.Accordingly, in the example of FIG. 3, the tire 200 is in a positionsuch that the accelerometer 304 is in its vertically lowest position(e.g., below the central axis of the tire 200).

In the illustrated example of FIG. 3, the accelerometer 304 can recordacceleration in the X, Y, and Z directions (e.g., axes) corresponding toa coordinate system 309 (e.g., a preprogrammed coordinate system 309 onthe accelerometer 304). In FIG. 3, the coordinate system 309 can be inoriented in any suitable direction, for example, to ease mounting of theaccelerometer 304 to the radially inner surface 306 of the tire 200. Forexample, in FIG. 3, the Z direction is oriented vertically on the page,the Y direction is oriented horizontally on the page, and the Xdirection is oriented into and out of the page according to an examplecoordinate system 309.

In FIG. 3, the example tire 200 includes example radially outer surfaces310 and example axially inner and outer shoulders 312, 314, collectivelyincluding the contact area 206 (FIG. 2) of the tire 200 with a surfaceupon which the vehicle 100 is being driven. Further, the tire 200includes example tread grooves 316 defining tread ribs 317 therebetween.When the tire 200 is exposed to adverse weather conditions such as rainand/or snow, water can be deflected away from the radially outersurfaces 310 into the tread grooves 316, increasing the traction of thetire 200. Though the tread grooves 316 are shown as circumferentialgrooves in the example of FIG. 3, the tread grooves 316 additionally oralternatively can be axial grooves, and/or grooves of any other anglebetween circumferential and axial on the radially outer surfaces 310and/or the shoulders 312, 314. Further, the tread grooves 316 need nottrace the circumference of the tire 200. For example, the tread grooves316 can trace any portion of the radially outer surfaces 310, theshoulders 312, 314, etc.

In the example of FIG. 3, an example tread depth 318 (e.g., a radialtread depth 318) of the tire 200 is indicated as the distance between anexample radially outer dashed line 320 and an example radially innerdashed line 322. In FIG. 3, the radially outer dashed line 320 isaligned with one or more of the radially outer surfaces 310 and theradially inner dashed line 322 is aligned with the radially inner depthof the tread grooves 316. Thus, the tread depth 318 is the distancebetween the radially outer surfaces 310 and the radially inner depth ofthe tread grooves 316. However, in other examples in accordance with theteachings of this disclosure, the tread depth 318 can be any suitabledepth and/or distance to indicate the wear of the tread ribs 317 and/orthe shoulders 312, 314 of the tire 200.

The tread depth 318 can be a measured tread depth 318 when the value ofthe tread depth 318 is measured by, for example, a tread depth gauge.The tread depth 318 can also be a predicted tread depth 318, when thevalue of the tread depth 318 is predicted using, for example, a treaddepth model.

During the rotation of the tire 200 (e.g., clockwise rotation) theaccelerometer 304 will experience a first deflection when the tire 200rotates such that the circumferential location on the tire 200 where theaccelerometer 304 is fixed encounters the first deflection point 208(FIG. 2). The accelerometer 304 will then experience a second deflectionwhen the tire 200 rotates such that the circumferential point encountersthe second deflection point 210 (FIG. 2). In the example of FIG. 3, theaccelerometer 304 is configured to record accelerations at thedeflections of the accelerometer 304, and to normalize and/or ignoreacceleration components that occur in the tire 200 due to rotation ofthe tire 200. For example, the tread depth 318 can affect theacceleration data of the deflection, enabling a correlation between theacceleration data and the tread depth 318. For example, the accelerationcaused by the material deformation of the tire 200 (e.g., deformation ofthe natural and/or synthetic materials) and/or deflection of the tire200 can change as the tread depth 318 of the tire 200 changes (e.g.,decreases).

FIG. 4 includes example first acceleration plots 400 depicting example Xdirection acceleration data 402, example Y direction acceleration data404, and example Z direction acceleration data 406 according to theconvention of FIG. 3 (e.g., the coordinate system 309). FIG. 4 alsoincludes a corresponding example first X direction acceleration datasegment 408, example first Y direction acceleration data segment 410,and example first Z direction acceleration data segment 412 segmentedbased on acceleration cycles. The X, Y, and Z direction accelerationdata 402, 404, 406 are also referred to as acceleration data 402, 404,406 herein. The first X, Y, and Z direction acceleration data segments408, 410, 412 are also referred to as first data segments 408, 410, 412herein. The X direction acceleration data 402 can be first accelerationdata 402, the Y direction acceleration data 404 can be secondacceleration data 404, and the Z direction acceleration data 406 can bethird acceleration data 406. The first X direction acceleration datasegment 408 can be a first data segment 408, the first Y directionacceleration data segment 410 can be a second data segment 410, and thefirst Z direction acceleration data segment 412 can be a third datasegment 412.

In the illustrated example of FIG. 4, the acceleration data 402-406 andthe corresponding first data segments 408-412, and, more generally, thefirst acceleration plots 400, have time in seconds (s) across theirhorizontal axes (e.g., primary axes, abscissa, etc.) and haveacceleration across their vertical axes (e.g., secondary axes, ordinate,etc.). The acceleration unit of the vertical axes of the firstacceleration plots 400 is the output unit of the accelerometer 304before a conversion to a standard unit, and the output unit representsrelative magnitude and sign in the first acceleration plots 400.

In the example of FIG. 4, the acceleration data 402-406 is accessed bythe on-board diagnostic module 102 (FIG. 1) from the accelerometer 304(FIG. 3) during operation of the vehicle 100 (FIG. 1) by way of thevehicle bus 114 (FIG. 1) over a time interval of two seconds. In otherexamples, the on-board diagnostic module 102 can access the accelerationdata 402-406 over any suitable time interval (e.g., 5 seconds, 20seconds, 2 minutes, etc.). For example, the accelerometer 304 cancontinuously transmit acceleration data 402-406 to the on-boarddiagnostic module 102. In this example, the acceleration data 402-406accounts for acceleration in three dimensions. In other examples, a twodimensional or one dimensional convention can be used. Further, thoughthe examples of FIG. 4 are discussed in connection with the vehicle 100and the on-board diagnostic module 102 for convenience, the examples ofFIG. 4 can be applied to the tread depth model controller 104 and one ormore accelerometers associated with one or more test vehicles.

In FIG. 4, the acceleration data 402-406 is associated with therevolutions of the tire 200 (FIG. 3). In the illustrated example of FIG.4, an example first time interval 414 associated with a revolution ofthe tire 200 is indicated between an example first line 416 and anexample second line 418 (e.g., the time between the first line 416 andthe second line 418). An example second time interval 420 associatedwith another revolution of the tire 200 is indicated between an examplethird line 422 and an example fourth line 424. In the example of FIG. 4,each of the time intervals 414, 420 represents at least a portion of arevolution of the tire 200. Though only the time intervals 414, 420 areannotated in FIG. 4, the acceleration data 402-406 includes a pluralityof intervals before, between, and after the time intervals 414, 420,each representing at least a portion of a revolution of the tire 200.The time spanned by the time intervals 414, 420 changes based on thespeed of the tire 200. In the example of FIG. 4, each of the intervals414, 420 includes an acceleration cycle. As used herein, the term“acceleration cycle” refers to the time interval associated with theaccelerometer 304 encountering both of the deflection points 208, 210.

In the illustrated example of FIG. 4, the X direction acceleration data402 includes a sequence of peaks and troughs within each time intervalsuch as the first time interval 414 and/or the second time interval 420.Each peak and trough in the X direction acceleration data 402 canrepresent an encounter of the accelerometer 304 with the firstdeflection point 208 and the second deflection point 210 respectively.In other examples, each peak and trough in the X direction accelerationdata 402 can represent an encounter of the accelerometer 304 with thesecond deflection point 210 and the first deflection point 208,respectively. In the X direction acceleration data 402, the peaks arepositive acceleration (e.g., +) and the troughs are negativeacceleration (e.g., −), both with relatively high magnitudes.

The Y direction acceleration data 404 includes two peaks with a troughdisposed therebetween for each time interval such as the first timeinterval 414 and/or the second time interval 420. However, the Ydirection acceleration data 404 includes largely positive accelerationthroughout the peaks and toughs. The Z direction acceleration data 406includes two peaks with a trough therebetween for each time intervalsuch as the first time interval 414 and/or the second time interval 420.In the examples of the Y and Z direction acceleration data 404, 406,each of the two peaks is associated with an encounter of theaccelerometer 304 with the first deflection point 208 and the seconddeflection point 210, respectively.

In the illustrated example of FIG. 4, the on-board diagnostic module 102can execute one or more processing steps with the acceleration data402-406. For example, the on-board diagnostic module 102 can apply amoving-average filter to the acceleration data 402-406 to smooth thedata. Additionally or alternatively, the on-board diagnostic module 102can apply any suitable filtering technique to the acceleration data402-406. Further, the on-board diagnostic module 102 can apply filteringtechniques such as the moving-average filter to the first data segments408-412.

In FIG. 4, the on-board diagnostic module 102 can segment the Xdirection acceleration data 402 into the first X direction accelerationdata segment 408, segment the Y direction acceleration data 404 into thefirst Y direction acceleration data segment 410, and segment the Zdirection acceleration data 406 into the first Z direction accelerationdata segment 412. For example, each of the first data segments 408-412can be the portion of the respective directional components of theacceleration data 402-406 for the first time interval 414, the secondtime interval 420, or any other time interval including where theaccelerometer 304 encounters the deflection points 208, 210 (e.g.,cycles). In other examples, the first data segments 408-412 can be theaverage and/or aggregation of two or more of the time intervals 414,420, etc. For example, the on-board diagnostic module 102 can determinethat a portion or portions of the acceleration data 402-406 is suitableto be segmented into the first data segments 408-412 randomly,sequentially, and/or based on predetermined criteria. In some examples,the first data segments 408-412 can encompass a single accelerationcycle in each of the X, Y, and Z directions, also referred to as asingle strike in each of the X, Y, and Z directions. In some examples,the on-board diagnostic module 102 can additionally or alternativelyapply the processing aspects such as the moving-average filter to thefirst data segments 408-412.

In the illustrated example of FIG. 4, the first X direction accelerationdata segment 408 includes an example first peak 426 and an example firsttrough 428. In FIG. 4, the first peak 426 is associated with anencounter of the accelerometer 304 with the first deflection point 208.The first trough 428 is associated with an encounter of theaccelerometer 304 with the second deflection point 210. The first Xdirection acceleration data segment 408 also includes first steady stateacceleration sections 430 that are not associated the first peak 426 andfirst trough 428 and are instead associated with the time of therevolution of the tire 200 outside of the contact area 206 (e.g., thetime of revolution of the tire 200 between the second deflection point210 and the first deflection point 208). The first steady stateacceleration sections 430 include local minima and maxima as well,noise, and/or distortion, for example, due to acceleration events causedby vibration, and/or surface roughness of the surface upon which thevehicle 100 is driving, etc.

In the illustrated example of FIG. 4, the first Y direction accelerationdata segment 410 includes an example second peak 432, an example thirdpeak 434, and an example second trough 436 disposed therebetween. InFIG. 4, the second peak 432 is associated with an encounter of theaccelerometer 304 with the first deflection point 208. The third peak434 is associated with an encounter of the accelerometer 304 with thesecond deflection point 210. The first Y direction acceleration datasegment 410 also includes second steady state sections 438, includinglocal minima and maxima, noise, and/or distortion, for example, due toacceleration events caused by vibration, and/or surface roughness of thesurface upon which the vehicle 100 is driving, etc.

In the illustrated example of FIG. 4, the first Z direction accelerationdata segment 412 includes an example fourth peak 440, an example fifthpeak 442, and an example third trough 444 disposed therebetween. In FIG.4, the fourth peak 440 is associated with an encounter of theaccelerometer 304 with the first deflection point 208. The fifth peak442 is associated with an encounter of the accelerometer 304 with thesecond deflection point 210. The first Z direction acceleration datasegment 412 also includes third steady state sections 446, includinglocal minima and maxima, noise, and/or distortion, for example, due toacceleration events caused by vibration, and/or surface roughness of thesurface upon which the vehicle 100 is driving, etc. In FIG. 4, the firstZ direction acceleration data segment 412 displays similar behavior tothat of the first Y direction acceleration data segment 410 at a highermagnitude than the magnitude of the first Y direction acceleration datasegment 410.

In the illustrated example of FIG. 4, the first data segments 408-412include a similar pattern (e.g., cycles, strikes, etc.) to the patternrepeated in the respective acceleration data 402-406. Thus, the firstdata segments 408-412 are a suitable proxy for the acceleration data402-406 for the purpose of training the tread depth status model.

FIG. 5 includes second example acceleration plots 500 depicting theexample X direction acceleration data 402, the example Y directionacceleration data 404, and the example Z direction acceleration data 406of FIG. 4. The second acceleration plots 500 also depict an examplesecond X direction acceleration data segment 502 and an example third Xdirection acceleration data segment 504, both corresponding to the Xdirection acceleration data 402. The second acceleration plots 500 alsodepict an example second Y direction acceleration data segment 506 andan example third Y direction acceleration data segment 508, bothcorresponding to the Y direction acceleration data 404. The secondacceleration plots 500 also depict an example second Z directionacceleration data segment 510 and an example third Z directionacceleration data segment 512.

The second X, Y, and Z direction acceleration data segments 502, 506,510 are also referred to herein as second data segments 502, 506, 510.The third X, Y, and Z direction acceleration data segments 504, 508, 512are also referred to herein as third data segments 504, 508, 512.Further, the second X direction acceleration data segment 502 can be afirst data segment 502 and the third X direction acceleration datasegment 504 can be a first data segment 504. The second Y directionacceleration data segment 506 can be a second data segment 506 and thethird Y direction acceleration data segment 508 can be a second datasegment 508. The second Z direction acceleration data segment 510 can bea third data segment 510 and the third Z direction acceleration datasegment 512 can be a third data segment 512.

Like the first acceleration plots 400 of FIG. 4, the second accelerationplots 500 have time in seconds (s) across their horizontal axes (e.g.,primary axes, abscissa, etc.) and have acceleration across theirvertical axes (e.g., secondary axes, ordinate, etc.). The accelerationunit of the vertical axes of the second acceleration plots 500 is theoutput unit of the accelerometer 304 before a conversion to a standardunit, and the output unit represents relative magnitude and sign in thesecond acceleration plots 500.

More generally, in the illustrated example of FIG. 5, the secondacceleration plots 500 include a basis for segmenting the accelerationdata 402-406 that can be used additionally or alternatively to the basisfor segmenting the first acceleration plots 400 of FIG. 4 (e.g., thefirst data segments 408-412). In the example of the second accelerationplots 500, segments of a common time interval (e.g., a time segment) arechosen from the acceleration data 402-406. In FIGS. 4-5, theacceleration data 402-406 is depicted on the time interval of zero totwo seconds. The on-board diagnostic module 102 can select, for example,the time interval from zero to one second for each of the accelerationdata 402-406 to form the second data segments 502, 506, 510.Additionally or alternatively, the on-board diagnostic module 102 canselect, for example, the time interval from one to two seconds from eachof the acceleration data 402-406 to form the third data segments 504,508, 512. In each of these examples, a segment of a relatively shortertime interval is selected from acceleration data of a relatively longertime interval. For example, the on-board diagnostic module 102 canreceive a constant stream of acceleration data from the accelerometer304 resembling the acceleration data 402-406 and can select data from afinite time interval to form a segment. Though the second and third datasegments 502-512 are shown on (e.g., span) a time interval of onesecond, a segment can be selected with any other length of time, such as0.1 seconds, 2 seconds, 10 seconds, 1 minute, etc.

In contrast to the first data segments 408-412 of FIG. 4, the datasegments of FIG. 5 (e.g., the second and third data segments 502-512)are segmented (e.g., formed, selected, etc.) without regard for theacceleration cycles (e.g., strikes, etc.) present within the segment.Any of the acceleration data 402-406 that falls within the selected timeinterval (e.g., zero to one second, zero to two seconds, etc.) will beincluded in the resulting acceleration data segment (e.g., the seconddata segments 502, 506, 510, the third data segments 504, 508, 512etc.).

In the illustrated example of FIG. 5, like FIG. 4, the on-boarddiagnostic module 102 can apply a moving-average filter to theacceleration data 402-406 to smooth the data. Additionally oralternatively, the on-board diagnostic module 102 can apply any suitablefiltering technique to the acceleration data 402-406. Further, theon-board diagnostic module 102 can apply filtering techniques such asthe moving-average filter to the second data segments 502, 506, 510and/or the third data segments 504, 508, 512.

In the illustrated examples of FIGS. 4 and 5, though the first andsecond acceleration plots 400, 500 are depicted graphically in acontinuous manner, the acceleration data 402-406 and the first, second,and third data segments 408-412, 502-512 can each be transmitted by theaccelerometer 304 as a digital and/or analog signal and stored on theon-board diagnostic module 102 and/or the tread depth model controller104 as a finite numerical data set for processing. For example, theaccelerometer 304 can record the acceleration data 402-406 at a discretesampling rate with a timestamp and can transmit the samples and theircorresponding timestamps to the tread depth model controller 104 and/orthe on-board diagnostic module 102, etc.

FIG. 6 is a block diagram of the example tread depth model controller104 of FIG. 1 to generate and/or train a tread depth status model. Theexample tread depth model controller 104 includes example first inputinterfaces 604, an example test controller 608, an example accelerationdata controller 612, an example tread depth determiner 618, an examplecontroller datastore 620, an example model generator 624, and an examplemodel provider 628. The example tread depth model controller 104 iscommunicatively coupled to the network 116 (FIG. 1) and to one or moretest vehicles.

In the illustrated example of FIG. 6, the tread depth model controller104 includes one or more first input interfaces 604 to access measuredtread depths 318 (FIG. 3), tread depth status model application data,additional data, etc. to train one or more tread depth status models.The first input interfaces 604 can include one or more networkinterfaces to receive information such as tread depth status modelapplication data from one or more on-board diagnostic modules 102(FIG. 1) via the network 116. For example, the first input interfaces604 can also access preset and/or manually input training data.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the example test controller 608 to conduct one or moretests to generate training data to generate a tread depth status model.In the illustrated example of FIG. 6, the test controller 608 can accessprocessed acceleration data including, for example, an augmented powerspectrum density (e.g., a single power spectrum density matrix and/orvector, etc.) from the acceleration data controller 612 and can accessthe measured tread depth 318 from the tread depth determiner 618 foreach test. The test controller 608 can also access available applicationdata such as the acceleration data 402-406 (FIG. 4), augmented powerspectrum densities, tread depth statuses, measured tread depths 318,and/or the additional data from one or more on-board diagnostic modules102. More generally, the test controller 608 can access training data togenerate (e.g., train) a tread depth status model.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the example acceleration data controller 612 to access,gather, and/or process the acceleration data 402-406 from theaccelerometer 304. The acceleration data controller 612 is discussed infurther detail in connection with FIG. 7.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the example tread depth determiner 618 to determine and/oraccess the measured tread depth 318 associated with one or more testvehicles. The tread depth determiner 618 can access tread depths thathave been manually measured by, for example, a tread depth gauge via thefirst input interfaces 604. Additionally or alternatively, the treaddepth determiner 618 can access tread depths measured by, for example,one or more sensors via the first input interfaces 604.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the example controller datastore 620 to store informationaccessed and/or processed by the tread depth model controller 104. Thecontroller datastore 620 can store the acceleration data 402-406,measured tread depths 318, tread depth status models, tread depth statusmodel application data, and/or additional data, all such datacollectively referred to as training data. The controller datastore 620can also store data such as the first, second, and/or third datasegments 408-412, 502-512 (FIGS. 4-5) and associated power spectrumdensities, the augmented power spectrum density, etc.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the model generator 624. The model generator 624 can accesstraining data and, in turn, generate a tread depth status model (e.g., apredictive model). The model generator 624 can access training data foreach test of a plurality of tests. The model generator 624 can access ameasured tread depth 318 and a corresponding augmented power spectrumdensity for each test of a plurality of tests along with applicationdata (e.g., collectively, the training data), and can use an AI and/orML model such as a SVM or a NN to generate (e.g., train) the tread depthstatus model (e.g., a predictive model) to predict a tread depth statusof the one or more tires 106-112 (FIG. 1) of a vehicle such as thevehicle 100. In some examples, the model generator 624 can generate aregression to predict the predicted tread depth 318 (e.g., a numericaltread depth value) based on, for example, the augmented power spectrumdensity.

In the illustrated example of FIG. 6, the tread depth model controller104 includes the model provider 628 to provide the one or more treaddepth status models (e.g., predictive models) generated by the modelgenerator 624 to one or more vehicles such as the vehicle 100. The modelprovider 628 can, for example, transmit the one or more tread depthstatus models to one or more of the on-board diagnostic modules 102 ofrespective vehicles 100 via the network 116. The model provider 628 canalso transmit the one or more tread depth status models to the vehicles100 via any number of wired or wireless mediums. For example, the modelprovider 628 may provide a model to an intermediate location where atread depth status model is preprogrammed (e.g., preset, preloaded,etc.) onto an ECU of a vehicle such as the vehicle 100.

FIG. 7 is a block diagram of the example acceleration data controller612 of FIG. 6 implemented in connection with the tread depth modelcontroller 104 of FIGS. 1 and/or 6 to access, gather, and/or process theacceleration data 402-406 FIG. 4. The example acceleration datacontroller 612 is also implemented in connection with the on-boarddiagnostic module 102 of FIG. 1 and is discussed further FIG. 8. In FIG.7, the acceleration data controller 612 includes an exampleaccelerometer interface 704, an example data smoother 708, an exampledata segmenter 712, an example power spectrum generator 716, and anexample data augmenter 720.

In the illustrated example of FIG. 7, the acceleration data controller612 includes the example accelerometer interface 704 to access and/orreceive the acceleration data 402-406 from the accelerometer 304 (FIG.3) of a vehicle such as the vehicle 100 and/or one or more testvehicles. In FIG. 7, the accelerometer interface 704 can access theacceleration data 402-406 via one or more wired or wireless connections(e.g., one or more receivers, one or more transceivers, etc.). Forexample, the accelerometer interface 704 can access the accelerationdata 402-406 contained in an analog and/or digital signal via a vehiclebus such as the vehicle bus 114 of FIG. 1 (via a wired or wirelessconnection such as a CAN bus and/or RF module such as a Bluetooth®interface, a NFC interface, etc.). In some examples, the accelerometerinterface 704 can access acceleration data in a continuous manner duringoperation of the vehicle from the accelerometer 304. In some examples,the accelerometer interface 704 can access the acceleration data 402-406a discrete manner (e.g., a digital signal) during and/or shortly afterthe acceleration data 402-406 is recorded by the accelerometer 304. Inthese examples, the accelerometer interface 704 can access discreteacceleration samples. In some examples, the accelerometer interface 704can access a particular time interval of acceleration data 402-406 afterthe accelerometer 304 has recorded the acceleration data.

In the illustrated example of FIG. 7, the acceleration data controller612 includes the data smoother 708 to apply one/or more filteringtechniques to the acceleration data 402-406 to remove noise (e.g.,irregular data) from the acceleration data 402-406. For example, thedata smoother 708 can apply a moving average filter to the accelerationdata 402-406 by taking the average of a preceding number of samples n,with or without weighting, to produce an acceleration data point infiltered acceleration data. The data smoother 708 can additionally oralternatively apply other filtering techniques, such as a low passfilter. The data smoother 708 can apply the one or more filteringtechniques before or after the representation of the acceleration data402-406 in FIG. 4.

In the illustrated example of FIG. 7, the acceleration data controller612 includes the data segmenter 712 to segment the acceleration data402-406 into data segments such as the first, second, and/or third datasegments 408-412, 502-512. The data segmenter 712 can segment theacceleration data 402-406 into the first data segments 408-412 such thatthe first data segments 408-412 encompass a single acceleration cycle(e.g., a partial or whole revolution of the tire 200 such that theaccelerometer 304 encounters the deflection points 208, 210 of FIG. 2).For example, the data segmenter 712 can aggregate and/or average two ormore cycles (e.g., strikes) to produce a segment. Additionally oralternatively, the data segmenter 712 can segment the acceleration data402-406 into the second data segments 502, 506, 510 and the third datasegments 504, 508, 512 based on, for example, a predetermined and/orsuitable time interval.

In the illustrated example of FIG. 7, the acceleration data controller612 includes the power spectrum generator 716 to generate the augmentedpower spectrum density of one or more data segments such as the first,second, and/or third data segments 408-412, 502-512. The power spectrumgenerator 716 can generate a first power spectrum density associatedwith the first X direction acceleration data segment 408, the second Xdirection acceleration data segment 502, and/or the third accelerationdata segment 504. The power spectrum generator 716 can generate a secondpower spectrum density associated with the first Y directionacceleration data segment 410, the second Y direction acceleration datasegment 506, and/or the third Y direction acceleration data segment 508.The power spectrum generator 716 can generate a third power spectrumdensity associated with the first Z direction acceleration data segment412, the second Z direction acceleration data segment 510, and/or thethird Z direction acceleration data segment 512. In other examples, thepower spectrum generator 716 can generate another value, vector, and/orspectrum (e.g., a statistic) representative of the first, second, and/orthird data segments 408-412, 502-512 (e.g., a weighted average, anenergy spectral density, etc.) and/or an augmented data segment, etc.

In the illustrated example of FIG. 7, the acceleration data controller612 includes the data augmenter 720 to augment one or more data sourcesinto an augmented and/or aggregated data. The data augmenter 720 can,for example, augment the first, second, and/or third power spectrumdensities generated by the power spectrum generator 716 into theaugmented power spectrum density by placing each of the first, second,and/or third power spectrum densities in a single matrix and/or vector.

While an example manner of implementing the tread depth model controller104 is illustrated in FIGS. 1, 6, and/or 7, one or more of the elements,processes and/or devices illustrated in FIGS. 1, 6, and/or 7 may becombined, divided, re-arranged, omitted, eliminated and/or implementedin any other way. Further, the example accelerometer interface 704, theexample data smoother 708, the example data segmenter 712, the examplepower spectrum generator 716, the example data augmenter 720, and/or,more generally, the example acceleration data controller 612 of FIGS. 6and/or 7, the example first input interfaces 604, the example testcontroller 608, the example acceleration data controller 612, theexample tread depth determiner 616, the example model generator 624, theexample model provider 628, and/or, more generally, the example treaddepth model controller 104 of FIGS. 1, 6, and/or 7 may be implemented byhardware, software, firmware and/or any combination of hardware,software and/or firmware. Thus, for example, any of the exampleaccelerometer interface 704, the example data smoother 708, the exampledata segmenter 712, the example power spectrum generator 716, theexample data augmenter 720, and/or, more generally, the exampleacceleration data controller 612 of FIGS. 6 and/or 7, the example firstinput interfaces 604, the example test controller 608, the exampleacceleration data controller 612, the example tread depth determiner616, the example model generator 624, the example model provider 628,and/or, more generally, the example tread depth model controller 104 ofFIGS. 1, 6, and/or 7 could be implemented by one or more analog ordigital circuit(s), logic circuits, programmable processor(s),programmable controller(s), graphics processing unit(s) (GPU(s)),digital signal processor(s) (DSP(s)), application specific integratedcircuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the exampleaccelerometer interface 704, the example data smoother 708, the exampledata segmenter 712, the example power spectrum generator 716, theexample data augmenter 720, and/or, more generally, the exampleacceleration data controller 612 of FIGS. 6 and/or 7, the example firstinput interfaces 604, the example test controller 608, the exampleacceleration data controller 612, the example tread depth determiner616, the example model generator 624, the example model provider 628,and/or, more generally, the example tread depth model controller 104 ofFIGS. 1, 6, and/or 7 is/are hereby expressly defined to include anon-transitory computer readable storage device or storage disk such asa memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-raydisk, etc. including the software and/or firmware. Further still, theexample tread depth model controller 104 of FIGS. 1, 6, and/or 7 mayinclude one or more elements, processes and/or devices in addition to,or instead of, those illustrated in FIGS. 1, 6, and/or 7, and/or mayinclude more than one of any or all of the illustrated elements,processes and devices. As used herein, the phrase “in communication,”including variations thereof, encompasses direct communication and/orindirect communication through one or more intermediary components, anddoes not require direct physical (e.g., wired) communication and/orconstant communication, but rather additionally includes selectivecommunication at periodic intervals, scheduled intervals, aperiodicintervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readableinstructions, hardware implemented state machines, and/or anycombination thereof for implementing the tread depth model controller104 of FIGS. 1, 6, and/or 7 are shown in FIGS. 9, 10, and/or 11. Themachine readable instructions may be one or more executable programs orportion(s) of an executable program for execution by a computerprocessor such as the processor 1212 shown in the example processorplatform 1200 discussed below in connection with FIG. 12. The programmay be embodied in software stored on a non-transitory computer readablestorage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, aBlu-ray disk, or a memory associated with the processor 1212, but theentire program and/or parts thereof could alternatively be executed by adevice other than the processor 1212 and/or embodied in firmware ordedicated hardware. Further, although the example program is describedwith reference to the flowcharts illustrated in FIGS. 9, 10, and/or 11,many other methods of implementing the example tread depth modelcontroller 104 may alternatively be used. For example, the order ofexecution of the blocks may be changed, and/or some of the blocksdescribed may be changed, eliminated, or combined. Additionally oralternatively, any or all of the blocks may be implemented by one ormore hardware circuits (e.g., discrete and/or integrated analog and/ordigital circuitry, an FPGA, an ASIC, a comparator, anoperational-amplifier (op-amp), a logic circuit, etc.) structured toperform the corresponding operation without executing software orfirmware.

The machine readable instructions described herein may be stored in oneor more of a compressed format, an encrypted format, a fragmentedformat, a compiled format, an executable format, a packaged format, etc.Machine readable instructions as described herein may be stored as data(e.g., portions of instructions, code, representations of code, etc.)that may be utilized to create, manufacture, and/or produce machineexecutable instructions. For example, the machine readable instructionsmay be fragmented and stored on one or more storage devices and/orcomputing devices (e.g., servers). The machine readable instructions mayrequire one or more of installation, modification, adaptation, updating,combining, supplementing, configuring, decryption, decompression,unpacking, distribution, reassignment, compilation, etc. in order tomake them directly readable, interpretable, and/or executable by acomputing device and/or other machine. For example, the machine readableinstructions may be stored in multiple parts, which are individuallycompressed, encrypted, and stored on separate computing devices, whereinthe parts when decrypted, decompressed, and combined form a set ofexecutable instructions that implement a program such as that describedherein.

In another example, the machine readable instructions may be stored in astate in which they may be read by a computer, but require addition of alibrary (e.g., a dynamic link library (DLL)), a software development kit(SDK), an application programming interface (API), etc. in order toexecute the instructions on a particular computing device or otherdevice. In another example, the machine readable instructions may needto be configured (e.g., settings stored, data input, network addressesrecorded, etc.) before the machine readable instructions and/or thecorresponding program(s) can be executed in whole or in part. Thus, thedisclosed machine readable instructions and/or corresponding program(s)are intended to encompass such machine readable instructions and/orprogram(s) regardless of the particular format or state of the machinereadable instructions and/or program(s) when stored or otherwise at restor in transit.

The machine readable instructions described herein can be represented byany past, present, or future instruction language, scripting language,programming language, etc. For example, the machine readableinstructions may be represented using any of the following languages: C,C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language(HTML), Structured Query Language (SQL), Swift, etc.

As mentioned above, the example processes of FIGS. 9, 10, and/or 11 maybe implemented using executable instructions (e.g., computer and/ormachine readable instructions) stored on a non-transitory computerand/or machine readable medium such as a hard disk drive, a flashmemory, a read-only memory, a compact disk, a digital versatile disk, acache, a random-access memory and/or any other storage device or storagedisk in which information is stored for any duration (e.g., for extendedtime periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm non-transitory computer readable medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals and to exclude transmission media.

“Including” and “comprising” (and all forms and tenses thereof) are usedherein to be open ended terms. Thus, whenever a claim employs any formof “include” or “comprise” (e.g., comprises, includes, comprising,including, having, etc.) as a preamble or within a claim recitation ofany kind, it is to be understood that additional elements, terms, etc.may be present without falling outside the scope of the correspondingclaim or recitation. As used herein, when the phrase “at least” is usedas the transition term in, for example, a preamble of a claim, it isopen-ended in the same manner as the term “comprising” and “including”are open ended. The term “and/or” when used, for example, in a form suchas A, B, and/or C refers to any combination or subset of A, B, C such as(1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) Bwith C, and (7) A with B and with C. As used herein in the context ofdescribing structures, components, items, objects and/or things, thephrase “at least one of A and B” is intended to refer to implementationsincluding any of (1) at least one A, (2) at least one B, and (3) atleast one A and at least one B. Similarly, as used herein in the contextof describing structures, components, items, objects and/or things, thephrase “at least one of A or B” is intended to refer to implementationsincluding any of (1) at least one A, (2) at least one B, and (3) atleast one A and at least one B. As used herein in the context ofdescribing the performance or execution of processes, instructions,actions, activities and/or steps, the phrase “at least one of A and B”is intended to refer to implementations including any of (1) at leastone A, (2) at least one B, and (3) at least one A and at least one B.Similarly, as used herein in the context of describing the performanceor execution of processes, instructions, actions, activities and/orsteps, the phrase “at least one of A or B” is intended to refer toimplementations including any of (1) at least one A, (2) at least one B,and (3) at least one A and at least one B.

As used herein, singular references (e.g., “a”, “an”, “first”, “second”,etc.) do not exclude a plurality. The term “a” or “an” entity, as usedherein, refers to one or more of that entity. The terms “a” (or “an”),“one or more”, and “at least one” can be used interchangeably herein.Furthermore, although individually listed, a plurality of means,elements or method actions may be implemented by, e.g., a single unit orprocessor. Additionally, although individual features may be included indifferent examples or claims, these may possibly be combined, and theinclusion in different examples or claims does not imply that acombination of features is not feasible and/or advantageous.

FIG. 8 is a block diagram of the example on-board diagnostic module 102of FIG. 1 to apply a tread depth status model to determine a tread depthstatus of a vehicle such as the vehicle 100 of FIG. 1. The exampleon-board diagnostic module 102 includes example second input interfaces804, the example acceleration data controller 612 of FIG. 7, an examplestatus controller 808, an example local datastore 812, and an exampleoutput handler 816. The example tread depth model controller 104 iscommunicatively coupled to the network 116 and to the vehicle bus 114,both of FIG. 1, of the vehicle 100. For example, the on-board diagnosticmodule 102 can be implemented by an ECU of the vehicle 100.

The second input interfaces 804 can include one or more networkinterfaces to receive information (e.g., tread depth status models) fromthe tread depth model controller 104 (FIG. 1) via the network 116. Forexample, the second input interfaces 804 can include any number of wiredor wireless connections to access, for example, one or more tread depthstatus models. For example, one or more tread depth status models can bepreloaded and/or preset on the on-board diagnostic module 102 via thesecond input interfaces 804. The second input interfaces 804 can accessavailable additional data (e.g., tire and/or vehicle make, model, size,age, usage, vehicle load, vehicle speed, tire pressure, temperatureetc.) associated with the vehicle 100.

In the illustrated example of FIG. 8, the on-board diagnostic module 102includes the example acceleration data controller 612 to access, gather,and/or process acceleration data such as acceleration data 402-406 (FIG.4) from the accelerometer 304 (FIG. 3) of the vehicle 100. Theacceleration data controller 612 is discussed in further detail inconnection with FIG. 7. In the illustrated example of FIG. 8, theacceleration data controller 612 of the on-board diagnostic module 102is physically distinct from the acceleration data controller 612 of thetread depth model controller 104. Accordingly, the acceleration datacontroller 612 of the on-board diagnostic module 102 can operateindependently of the acceleration data controller 612 of the tread depthmodel controller 104.

In the illustrated example of FIG. 8, the on-board diagnostic module 102includes the status controller 808 to determine a tread depth status ofthe vehicle 100. The status controller 808 can receive an augmentedpower spectrum density from the acceleration data controller 612 and/orpast tread depth status model applications for the vehicle 100. In turn,the status controller 808 can apply a tread depth status model todetermine a tread depth status of one or more of the tires 106-112(FIG. 1) associated with the vehicle 100. In some examples, the statuscontroller 808 can receive the augmented power spectrum density from theacceleration data controller 612 and can generate (e.g., predict), basedon a tread depth model including a regression, the predicted tread depth318.

In the illustrated example of FIG. 8, the on-board diagnostic module 102includes the local datastore 812. The local datastore 812 is configuredto store one or more tread depth status models, one or more tread depthstatuses of the vehicle 100, one or more tread depth models, one or morepredicted tread depths 318, additional data associated with the vehicle100, and/or data associated with the acceleration data controller 612.The data associated with the acceleration data controller 612 caninclude the acceleration data 402-406, the first, second, and/or thirddata segments 408-412, 502-512, first second and third power spectrumdensities associated with the first, second, and/or third data segments408-412, 502-512, single augmented power spectrum densities, singleaugmented data segments, etc.

In the illustrated example of FIG. 8, the on-board diagnostic module 102includes the output handler 816 to provide a tread depth statusdetermination of the tread depth status model to, for example, thedisplay 115 (FIG. 1) of the vehicle 100. For example, the output handler816 can provide a tread depth status indicative of a tread depth rangeand/or a tread depth status indicative of a tread depth satisfying athreshold to the display 115. The output handler 816 can provide a treaddepth status to the display 115 of the vehicle 100, for example, via thevehicle bus 114. For example, the output handler 816 can provide anumerical predicted tread depth 318 to the display 115.

While an example manner of implementing the on-board diagnostic module102 is illustrated in FIGS. 1, 7, and/or 8, one or more of the elements,processes and/or devices illustrated in FIG. 5 may be combined, divided,re-arranged, omitted, eliminated and/or implemented in any other way.Further, the example accelerometer interface 704, the example datasmoother 708, the example data segmenter 712, the example power spectrumgenerator 716, and/or, more generally, the example acceleration datacontroller 612 of FIGS. 7 and/or 8, the example second input interfaces804, the example status controller 808, the example output handler 816and/or, more generally, the example on-board diagnostic module 102 ofFIGS. 1, 7, and/or 8 may be implemented by hardware, software, firmwareand/or any combination of hardware, software and/or firmware. Thus, forexample, any of the example accelerometer interface 704, the exampledata smoother 708, the example data segmenter 712, the example powerspectrum generator 716, and/or, more generally, the example accelerationdata controller 612 of FIGS. 7 and/or 8, the example second inputinterfaces 804, the example status controller 808, the example outputhandler 816 and/or, more generally, the example on-board diagnosticmodule 102 of FIGS. 1, 7, and/or 8 could be implemented by one or moreanalog or digital circuit(s), logic circuits, programmable processor(s),programmable controller(s), GPU(s), DSP(s), ASIC(s), PLD(s) and/orFPLD(s). When reading any of the apparatus or system claims of thispatent to cover a purely software and/or firmware implementation, atleast one of the example accelerometer interface 704, the example datasmoother 708, the example data segmenter 712, the example power spectrumgenerator 716, and/or, more generally, the example acceleration datacontroller 612 of FIGS. 7 and/or 8, the example second input interfaces804, the example status controller 808, the example output handler 816and/or, more generally, the example on-board diagnostic module 102 ofFIGS. 1, 7, and/or 8 is/are hereby expressly defined to include anon-transitory computer readable storage device or storage disk such asa memory, DVD, CD, a Blu-ray disk, etc. including the software and/orfirmware. Further still, the example on-board diagnostic module 102 ofFIGS. 1, 7, and/or 8 may include one or more elements, processes and/ordevices in addition to, or instead of, those illustrated in FIGS. 1, 7,and/or 8, and/or may include more than one of any or all of theillustrated elements, processes and devices. As used herein, the phrase“in communication,” including variations thereof, encompasses directcommunication and/or indirect communication through one or moreintermediary components, and does not require direct physical (e.g.,wired) communication and/or constant communication, but ratheradditionally includes selective communication at periodic intervals,scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readableinstructions, hardware implemented state machines, and/or anycombination thereof for implementing the on-board diagnostic module 102of FIGS. 1, 7, and/or 8 are shown in FIGS. 9 and/or 11. The machinereadable instructions may be one or more executable programs orportion(s) of an executable program for execution by a computerprocessor such as the processor 1312 shown in the example processorplatform 1300 discussed below in connection with FIG. 7. The program maybe embodied in software stored on a non-transitory computer readablestorage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, aBlu-ray disk, or a memory associated with the processor 1312, but theentire program and/or parts thereof could alternatively be executed by adevice other than the processor 1312 and/or embodied in firmware ordedicated hardware. Further, although the example program is describedwith reference to the flowchart illustrated in FIG. 5, many othermethods of implementing the example on-board diagnostic module 102 mayalternatively be used. For example, the order of execution of the blocksmay be changed, and/or some of the blocks described may be changed,eliminated, or combined. Additionally or alternatively, any or all ofthe blocks may be implemented by one or more hardware circuits (e.g.,discrete and/or integrated analog and/or digital circuitry, an FPGA, anASIC, a comparator, an operational-amplifier (op-amp), a logic circuit,etc.) structured to perform the corresponding operation withoutexecuting software or firmware.

As mentioned above, the example processes of FIGS. 9 and/or 11 may beimplemented using executable instructions (e.g., computer and/or machinereadable instructions) stored on a non-transitory computer and/ormachine readable medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information).

FIG. 9 is a flowchart representative of machine readable instructions900 which may be executed to implement the example tread depth modelcontroller 104 of FIGS. 1 and/or 6, the example acceleration datacontroller 612 of FIGS. 6, 7, and/or 8, and/or the example on-boarddiagnostic module 102 of FIGS. 1 and/or 8 for an example training phase902 and an example operation phase 904. The examples of FIG. 9 use AI/MLto train and deploy an example tread depth status model to determine atread depth status of the example tires 106-112 of the vehicle 100 ofFIG. 1.

AI, including ML, deep learning (DL), and/or other artificialmachine-driven logic, enables machines (e.g., computers, logic circuits,etc.) to use a model to process input data to generate an output basedon patterns and/or associations previously learned by the model via atraining process. For instance, the model may be trained with data torecognize patterns and/or associations and follow such patterns and/orassociations when processing input data such that other input(s) resultin output(s) consistent with the recognized patterns and/orassociations.

Many different types of machine learning models and/or machine learningarchitectures exist. In some examples disclosed herein, an SVM and/or NNmodel is used. Using an SVM and/or a NN model enables the modelgenerator 624 of the tread depth model controller 104 to generate apredictive tread depth status model to predict a tread depth statusbased on input data (e.g., the augmented power spectrum density, etc.).In general, machine learning models/architectures that are suitable touse in the example approaches disclosed herein will be supervisedlearning ML/AI models such as an SVM and/or NN to produce a tread depthstatus model (e.g., a tread depth classification model) based on labeledtraining data. However, other types of machine learning models couldadditionally or alternatively be used such as unsupervised learningmodels, etc.

In general, implementing a ML/AI system involves two phases, alearning/training phase (e.g., the training phase 902) and an inferencephase (e.g., the operation phase 904). In the learning/training phase, atraining algorithm is used to train a model to operate in accordancewith patterns and/or associations based on, for example, training data.In general, the model includes internal parameters that guide how inputdata is transformed into output data, such as through a series of nodesand connections within the model to transform input data into outputdata. Additionally, hyperparameters are used as part of the trainingprocess to control how the learning is performed (e.g., a learning rate,a number of layers to be used in the machine learning model, etc.).Hyperparameters are defined to be training parameters that aredetermined prior to initiating the training process.

Different types of training may be performed based on the type of ML/AImodel and/or the expected output. For example, supervised training usesinputs and corresponding expected (e.g., labeled) outputs to selectparameters (e.g., by iterating over combinations of select parameters)for the ML/AI model that reduce model error. As used herein, labellingrefers to an expected output of the machine learning model (e.g., aclassification, an expected output value, a target variable, etc.). Insome examples disclosed herein, the labeled outputs (e.g., the targetvariables) are tread depth statuses and/or tread depths. Alternatively,unsupervised training (e.g., used in deep learning, a subset of machinelearning, etc.) involves inferring patterns from inputs to selectparameters for the ML/AI model (e.g., without the benefit of expected(e.g., labeled) outputs).

In examples disclosed herein, ML/AI models are trained using stochasticgradient descent. However, any other training algorithm may additionallyor alternatively be used. In examples disclosed herein, training isperformed until an acceptable amount of error is achieved. In examplesdisclosed herein, training is performed at a central facility inconnection with the model generator 624 (FIG. 6) and, more generally,the tread depth model controller 104. Training is performed usinghyperparameters that control how the learning is performed (e.g., alearning rate, a number of layers to be used in the machine learningmodel, etc.). In some examples re-training may be performed. Suchre-training may be performed in response to additional training databecoming available, for example, when the tread depth model controller104 accesses additional tests and/or application data from one or moreof the on-board diagnostic modules 102 and/or, for example, measuredtread depths 318 corresponding to the respective vehicles 100 of theon-board diagnostic modules 102.

Training is performed using training data. In examples disclosed herein,the training data primarily originates from tests conducted at thecentral facility with test vehicles. Because supervised training isused, the training data is labeled. Labeling is applied to the trainingdata by determining the measured tread depth 318 (FIG. 3) associatedwith one or more tires 200 (FIG. 2) of the test vehicles and/or anexample measured tread depth status associated with the measured treaddepth 318 of the test vehicles. In some examples, the training data isprocessed using, for example, the tread depth determiner 618 (FIG. 6) toassign a measured tread depth status to the measured tread depth 318.For example, if the tread depth status model is to determine if thetread depth 318 is above a threshold (e.g., an acceptable status) orbelow a threshold (e.g., an unacceptable status), the tread depthdeterminer 618 can classify the measured tread depth 318 into a measuredtread depth status associated with augmented power spectrum density of atest. For example, if the threshold is 3/32 in., and the measured treaddepth 318 is 5/32 in., the tread depth determiner can assign a treaddepth status of acceptable to the power spectrum density. In somedisclosed examples, the training data is processed using, for example,the acceleration data controller 612 (FIG. 6) to generate the augmentedpower spectrum density from acceleration data such as the accelerationdata 402-406 (FIG. 4). In some examples, a portion of the training datais, for example, validation data.

Once training is complete, the tread depth status model is deployed foruse as an executable construct that processes an input and provides anoutput based on the network of nodes and connections defined in thetread depth status model. The tread depth status model is stored at thecontroller datastore 620 (FIG. 6) of the tread depth model controller104, and the model provider 628 (FIG. 6) provides the tread depth statusmodel to the local datastore 812 (FIG. 8) of one or more of the on-boarddiagnostic modules 102 associated with respective vehicles 100. Thetread depth status model may then be executed by the status controller808 (FIG. 8) of the on-board diagnostic module 102. In some examples,the status controller 808 and, more generally, the on-board diagnosticmodule 102 can execute the tread depth status model on an ECU of thevehicle 100.

Once trained, the deployed tread depth status model may be operated inan inference phase (e.g., the operation phase 904) to process data. Inthe inference phase, data to be analyzed (e.g., live data) is input tothe model, and the model executes to create an output. This inferencephase can be thought of as the AI “thinking” to generate the outputbased on what it learned from the training (e.g., by executing the modelto apply the learned patterns and/or associations to the live data). Insome examples, input data undergoes processing before being used as aninput to the machine learning model. Moreover, in some examples, theoutput data may undergo post-processing after it is generated by the AImodel to transform the output into a useful result (e.g., a display ofdata, an instruction to be executed by a machine, etc.).

In some examples, output of the deployed tread depth status model (e.g.,the application data) may be captured and provided as feedback to, forexample, the tread depth model controller 104. By analyzing thefeedback, an accuracy of the deployed tread depth status model can bedetermined. If the feedback indicates that the accuracy of the deployedmodel is less than a threshold or other criterion, training of anupdated model can be triggered using the feedback and an updatedtraining data set, hyperparameters, etc., to generate an updated,deployed model.

Returning now to FIG. 9, the machine readable instructions 900 of FIG. 9and the training phase 902 begin when the tread depth model controller104 accesses and processes training data to train a tread depth statusmodel. (Block 906). An example approach for accessing and processingtraining data is discussed in further detail in connection with FIG. 10.In FIG. 9, the first input interfaces 604, the test controller 608, thetread depth determiner 618, and/or the acceleration data controller 612of FIGS. 6 and/or 7 access and process the training data.

In some examples disclosed herein, the training data includes dataaccessed and/or processed from a plurality of tests conducted by thetest controller 608. The training data includes measured tread depthstatuses (e.g., “acceptable”, “unacceptable”, etc.). The measured treaddepth statuses are the prospective outputs, the labeled outputs, thetarget variables, etc. The training data also includes the augmentedpower spectrum densities associated with respective tests (e.g., theinputs). The training data can also include additional data for thetests and/or test vehicles (e.g., tire and/or vehicle make, model, size,age, usage, vehicle load, vehicle speed, tire pressure, temperatureetc.). The training data can also include application data frompreviously iterated tread depth status models including, for example,acceleration data 402-406, tread depth statuses, measured tread depths318, and/or measured tread depth statuses for vehicles 100. Though thetraining phase 902 is discussed in connection with machine readableinstructions 900, any portion of the training phase 902 can additionallyor alternatively be completed manually.

The model generator 624 (FIG. 6) of the tread depth model controller 104then generates a tread depth status model (e.g., a currently iteratedtread depth status model) based on the training data and/or previouslyiterated tread depth status models. (Block 908). For example, the modelgenerator 624 can use the training data in connection with a ML/AI modelsuch as a SVM and/or NN to generate a tread depth status model that canpredict a tread depth status based on input data (e.g., power spectrumdensities). Additionally or alternatively, in some examples, the modelgenerator 624 can generate a tread depth model to predict a numericaltread depth 318 using, for example, a regression.

The tread depth status can be one of, for example, “acceptable”indicating that the tread depth 318 exceeds a threshold, or“unacceptable” indicating that the tread depth 318 is below thethreshold and needs immediate attention. The tread depth threshold canbe, for example, 3/32 in. Additionally or alternatively, the tread depthstatus can be one of, for example, “good condition” indicating that thetread depth 318 is above a high threshold, “moderate wear condition”indicating that the tread depth 318 is between the high threshold and alow threshold, or “unacceptable” indicating that the tread depth 318 isbelow the low threshold an needs immediate attention. For example, thehigh threshold can be 7/32 in. and the low threshold can be 3/32 in. Inother examples, any other suitable range and number of thread depths 318and/or thresholds can be used.

The model provider 628 can provide (e.g., deploy) the tread depth statusmodel to the on-board diagnostic module 102 associated with the vehicle100. (Block 910). For example, the model provider 628 can provide thetread depth status model to the on-board diagnostic module 102 via thenetwork 116 (FIG. 1), during, for example a software update of thevehicle 100. Additionally or alternatively, the model provider 628 canprovide the tread depth status model to the second input interfaces 804(FIG. 8) of the on-board diagnostic module 102 via any suitable wiredand/or wireless connection during, for example, production of thevehicle 100 or a service event of the vehicle 100.

The operation phase 904 of the machine readable instructions 900 beginswhen the acceleration data controller 612 associated with the on-boarddiagnostic module 102 accesses and processes the acceleration data402-406. (Block 912). An example approach for accessing and processingthe acceleration data 402-406 is discussed in further detail inconnection with FIG. 11. The acceleration data controller 612 cangenerate the augmented power spectrum density associated with theacceleration data 402-406 for use as input data to the tread depthstatus model (e.g., the predictive model).

Though the operation phase 904 is discussed herein in connection with asingle on-board diagnostic module 102 associated with the vehicle 100,the tread depth status model generated by the tread depth modelcontroller 104 of the training phase 902 can be provided to a pluralityof on-board diagnostic modules 102 associated with respective vehicles100. Thus, the operation phase 904 can be implemented by the pluralityof on-board diagnostic modules 102 to determine tread depth status(es)for their respective vehicles 100.

The status controller 808 applies the tread depth status model (e.g.,the predictive model) to generate a tread depth status (e.g., aprediction) based on the augmented power spectrum density. (Block 916).For example, if the tread depth status model is trained to classify theinput data as associated with an acceptable tread depth 318 or anunacceptable tread depth 318, the status controller 808 can predict,using the input data with the tread depth status model, that the treaddepth status of one or more tires (e.g., one of the tires 106-112) isacceptable or unacceptable. Additionally or alternatively, for example,if the tread depth status model is trained to classify the input data asassociated with an acceptable tread depth 318, a tread depth 318 of amoderate wear condition, or an unacceptable tread depth 318, the treaddepth status model can predict using the input data with the tread depthstatus model that the tread depth status of the one or more tires isacceptable, unacceptable, or of a moderate wear condition.

In some examples, the tread depth status model can consider availableadditional data such as vehicle and tire make, model, tread depthhistory, vehicle load, vehicle speed, tire pressure, temperature etc.,when determining the tread depth status. In some examples, at block 916,the on-board diagnostic module 918 can predict a numerical tread depth318 with a tread depth model.

The output handler 816 provides the tread depth status to the display115 (FIG. 1) of the vehicle 100. (Block 918). The output handler 816 canprovide a tread depth status indicative of a likely tread depth range(e.g., acceptable, unacceptable, or moderate wear condition) and/or atread depth status indicative of the tread depth 318 satisfying athreshold (e.g., acceptable or unacceptable) to the display 115 (e.g.,an infotainment system, a dashboard warning light, etc.). The outputhandler 816 can provide a tread depth status to the display 115 of thevehicle 100, for example, via the vehicle bus 114, via the network 116,and/or via any other suitable wired or wireless connection. In someexample, the status controller 808 can produce two or more tread depthstatuses in order to increase confidence in the tread depth statusprediction before the output handler 816 presents the tread depth statusto the display 115.

In the examples disclosed herein, the on-board diagnostic module 102 candetermine a tread depth status and/or a tread depth of a single tire(e.g., the FL tire 106 of FIG. 1), two tires (e.g., the FL and FR tires106, 108 of FIG. 1), three tires (e.g., the FL, FR, and RL tires 106-110of FIG. 1), and/or four tires (e.g., the FL, FR, RL, and RR tires106-112 of FIG. 1), etc., of the vehicle 100, and the output handler 816can present the tread depth(s) and/or tread depth status(es) to thedisplay 115. The on-board diagnostic module 102 can determine a treaddepth and/or a tread depth status for each tire (e.g., the tires106-112) of the vehicle 100 based on acceleration data 402-406 from eachtire. Additionally or alternatively, the acceleration data 402-406 canbe generated for one or more tires (e.g., one or more of the tires106-112) including accelerometers 304 (e.g., tires with available data)and a tread depth and/or a tread depth status can be determined for theone or more tires. For example, the tread depth and/or tread depthstatus can be representative of tires (e.g., ones of the tires 106-112)not including accelerometers 304 (e.g., tires without available data).

In the example of FIG. 9, after block 918, control returns to block 912to again access and process acceleration data to generate anotherprediction of a tread depth status. In some examples, the on-boarddiagnostic module 102 will repeat the operation phase 904 from block 912to generate more tread depth statuses associated with the vehicle 100after a fixed time interval. In some examples, the on-board diagnosticmodule 102 will repeat the operation phase 904 from block 912 uponreceiving a command. The output handler 816 can additionally provide anestimate of the remaining life of a tire based on the tread depthstatus. For example, if, during iteration of the operation phase 904, ifthe tread depth status changes from “good condition” in one iteration to“moderate wear condition” in the next iteration, the output handler 816can predict the remaining tire life of ones of the tire 200 and canprovide the predicted remaining tire life to the display 115.

Now turning to FIG. 10, a flowchart representative of machine readableinstructions 1000 which may be executed to implement the example treaddepth model controller 104 of FIGS. 1 and/or 6 and the exampleacceleration data controller 612 of FIGS. 6 and/or 7 to gather andprocess training data for the example training phase 902 of FIG. 9. Themachine readable instructions 1000 begin when the acceleration datacontroller 612 associated with the tread depth model controller 104accesses and processes acceleration data 402-406 (FIG. 4) from one ormore tires 200 (FIG. 2) of a test vehicle for a test. (Block 1002). Anexample approach for accessing and processing acceleration data 402-406is discussed in further detail in connection with FIG. 11. Theacceleration data controller 612 can generate the augmented powerspectrum density associated with the acceleration data 402-406 for theone or more tires 200 of the test for use as training data for the treaddepth status model.

The tread depth determiner 618 (FIG. 6) determines the measured treaddepth 318 associated with the one or more tires 200 of the test vehiclefor the test and assigns a measured tread depth status (e.g., acceptabletread depth, unacceptable tread depth, moderate wear condition, etc.) tothe one or more tires 200 for use in the training data. (Block 1006). Inexamples disclosed herein, the tread depth status is the labeled output(e.g., the target variable) of the tread depth status model.Accordingly, the measured tread depth status is the component of thetraining data that is not present in the input data to a deployed treaddepth status model. At the conclusion of block 1006, a test is completedfor the training data and a data point for the training data has beendetermined. In some examples, the measured tread depth 318 and/or themeasured tread depth status is the same for a plurality of tests, butnew first, second, and/or third data segments 408-412, 502-512 areselected for each test of the plurality of tests. In some examples, thetest controller 608 can access additional data such as vehicle and tiremake, model, tread depth history, vehicle load, vehicle speed, tirepressure, temperature etc., for a test.

The test controller 608 determines whether it is desirable to conductanother test. (Block 1008). For example, the tread depth modelcontroller 104 can conduct a preset number of tests in order to completethe training data. If more tests are desired (e.g., block 1008 returnsYES), control returns to block 1002. If more tests are not desired(e.g., block 1010 returns NO), the test controller 608 determineswhether application data for previously deployed tread depth statusmodels is available. (Block 1010).

If application data is not available (e.g., block 1010 returns NO),control returns to the machine readable instructions 900 of FIG. 9 wherethe model generator 624 (FIG. 6) generates a tread depth status model.If application data is available (e.g., block 1010 returns YES), thetest controller 608 accesses available application data, includeacceleration data (e.g., acceleration data 402-406), tread depthstatutes, measured tread depths 318, and/or additional input datacollected during an application of a previous tread depth status modelwith one or more of the on-board diagnostic modules 102. (Block 1012).Control then returns to the machine readable instructions 900 of FIG. 9where the model generator 624 (FIG. 6) generates a tread depth statusmodel.

Now turning to FIG. 11, a flowchart representative of example machinereadable instructions 1100 which may be executed to implement theexample tread depth model controller 104 of FIGS. 1 and/or 6, theexample the acceleration data controller 612 of FIGS. 6, 7, and 8 and/orthe example on-board diagnostic module of FIGS. 1 and/or 8 to access andprocess acceleration data 402-406 of FIG. 4. In the illustrated exampleof FIG. 11, a first acceleration data controller 612 of the tread depthmodel controller 104 executes the machine readable instructions 1100 atfirst instances for one or more tests in connection with block 1002 ofFIG. 10 and the training phase 902 of FIG. 9 to access and processacceleration data for a test. In FIG. 11, a second acceleration datacontroller 612 of the on-board diagnostic module 102 executes themachine readable instructions 1100 at second instances in connectionwith block 912 of FIG. 9 and the operation phase 904 of FIG. 9 to accessand process acceleration data 402-406 to generate a tread depth status.

The machine readable instructions 1100 of FIG. 11 begin when theaccelerometer interface 704 of FIG. 7 accesses X direction accelerationdata 402, Y direction acceleration data 404, and Z directionacceleration data 406 from the accelerometer 304 (FIG. 3) associatedwith the tire 200 (FIG. 2). (Block 1102). The accelerometer interface704 can access the acceleration data 402-406 from the accelerometer 304(FIG. 3) associated with the tire 200, the acceleration data includingfirst acceleration data indicative of acceleration in a first direction(e.g., X direction acceleration data 402), second acceleration dataindicative of acceleration in a second direction (e.g., Y directionacceleration data 404), and third acceleration data indicative ofacceleration in a third direction (e.g., Z direction acceleration data406).

The data smoother 708 of FIG. 7 applies a moving average and/or low passfilter to the acceleration data 402-406 to reduce noise in theacceleration data 402-406. (Block 1104). In some examples, additionallyor alternatively, the data smoother 708 can apply any other suitablefiltering technique to the acceleration data 402-406. In some examples,additionally or alternatively, the data smoother 708 can apply themoving average filter, the low pass filter, and/or any other suitablefiltering technique at another stage of the machine readableinstructions 1100, or not apply any filter at all. For example, the datasmoother 708 can apply the one or more filters after the accelerationdata 402-406 has been segmented into the first, second, and/or thirddata segments 408-412, 502-512 of FIGS. 4 and/or 5.

The data segmenter 712 of FIG. 7 segments the acceleration data 402-406based on cycles (e.g., the first data segments 408-412) and/or based ontime intervals (e.g., the second data segments 502, 506, 510 and/or thethird data segments 504, 508, 512). (Block 1106). For example, the datasegmenter 712 can segment the first acceleration data (e.g., the Xdirection acceleration data 402) into a first data segment (e.g., thefirst X direction acceleration data segment 408, the second X directionacceleration data segment 502, and/or the third X direction accelerationdata segment 504). Similarly, the second acceleration data (e.g., the Ydirection acceleration data 404) can be segmented into a second datasegment (e.g., the first Y direction acceleration data segment 410, thesecond Y direction acceleration data segment 506, and/or the third Ydirection acceleration data segment 508). Likewise, the thirdacceleration data (e.g., the Z direction acceleration data 406) can besegmented into a third data segment (e.g., the first Z directionacceleration data segment 412, the second Z direction acceleration datasegment 510, and/or the third Z direction acceleration data segment 512)based on at least one of acceleration cycles or a common time interval.The data segmenter 712 can determine a primary cycle peak (e.g., thefirst peak 426, the second peak 432, and/or the fourth peak 440 of FIG.4) and set transition points to be halfway between two successiveprimary cycle peaks in each of the acceleration data 402-406. The datasegmenter 712 can segment the acceleration data 402-406 into first datasegments 408-412 based on cycles by assigning a beginning time for thedata segment at a first transition point and an ending time for the datasegment at a second transition point for each cycle.

In the illustrated example of FIG. 7, the data segmenter 712 can bepre-programed and/or preset to, for example, generate data segmentsbased on a common acceleration cycle or based on preset time intervals.In the machine readable instructions 1100, the data segmenter 712selects a single X direction acceleration data segment, a single Ydirection acceleration data segment, and a single Z directionacceleration data segment (e.g., the first data segments 408-412, thesecond data segments 502, 506, 510, or the third data segments 504, 508,512) for a test in connection with FIG. 10, and generates a depth statusin connection with the operation phase 904 of FIG. 9. Alternatively, thedata segmenter 712 can segment acceleration data into other datasegments not called out in FIGS. 4 and/or 5 based on an accelerationcycle or another time interval.

The power spectrum generator 716 generates power spectrum densities foreach data segment (e.g., the first, second, or third data segments408-412, 502-512). (Block 1108). In FIG. 7, the power spectrum generator716 can generate the power spectrum densities based on the illustratedexample of Equation (1) below.

$\begin{matrix}{P = {\lim\limits_{Tarrow\infty}{E\lbrack {{\hat{x}(\omega)}}^{2} \rbrack}}} & {{Equation}\mspace{14mu}(1)}\end{matrix}$

In the example of Equation (1) above, the function x(ω) represents thedata segment (e.g., one data segment of the first, second, or third datasegments 408-412, 502-512) expressed in the frequency domain. A vector Prepresents the power spectrum density of a data segment of the first,second, or third data segments 408-412, 502-512, or the distribution ofpower among the frequencies of the data segment expressed in thefrequency domain. The variable T represents the time interval of thedata segment.

In the illustrated example of FIG. 11, the power spectrum generator 716can generate a power spectrum density for each of a single X directionacceleration data segment, a single Y direction acceleration datasegment, and a single Z direction acceleration data segment according toEquation (1). Thus, at block 1108, the power spectrum generator 716 cangenerate power spectrum densities for the first data segments 408-412,the second data segments 502, 506, 510, or the third data segments 504,508, 512 according to Equation (1). Alternatively, the power spectrumgenerator can generate other power spectrum densities for other datasegments not called out in FIGS. 4 and/or 5 based on an accelerationcycle or another time interval according to Equation (1).

For example, the power spectrum generator 716 can generate a first powerspectrum density associated with the first data segment (e.g., the firstX direction acceleration data segment 408, the second X directionacceleration data segment 502, and/or the third X direction accelerationdata segment 504), a second power spectrum density associated with thesecond data segment (e.g., the first Y direction acceleration datasegment 410, the second Y direction acceleration data segment 506,and/or the third Y direction acceleration data segment 508), and a thirdpower spectrum density associated with the third data segment (e.g., thefirst Z direction acceleration data segment 412, the second Z directionacceleration data segment 510, and/or the third Z direction accelerationdata segment 512) according to Equation (1).

The data augmenter 720 of FIG. 7 augments the first power spectrumdensity, the second power spectrum density, and the third power spectrumdensity into a resultant augmented power spectrum density. (Block 1110).In this example, the augmented power spectrum density (e.g., a fourthpower spectrum density, a resultant power spectrum density, a combinedpower spectrum density, etc.) is a vector and/or matrix containing thepower spectrum densities for each of the first, second, and third powerspectrum densities. The vector and/or matrix is the independent variable(e.g., the predictor variable) for the tread depth status model.

If the machine readable instructions 1100 are executed in connectionwith block 1002 of FIG. 10 and the training phase 902 of FIG. 9, controlreturns to block 1004. If the machine readable instructions 1100 areexecuted in connection with block 912 of FIG. 9 and the operation phase904 of FIG. 9, control returns to block 914.

FIG. 12 is a block diagram of an example processor platform 1200structured to execute the instructions of FIGS. 9, 10, and/or 11 toimplement the tread depth model controller 104 of FIGS. 1, 6, and/or 7.The processor platform 1200 can be, for example, a server, a personalcomputer, a workstation, a self-learning machine (e.g., a neuralnetwork), a mobile device (e.g., a cell phone, a smart phone, a tabletsuch as an iPad™), a personal digital assistant (PDA), an Internetappliance, a DVD player, a CD player, a digital video recorder, aBlu-ray player, a gaming console, a personal video recorder, a set topbox, a headset or other wearable device, an ECU, or any other type ofcomputing device.

The processor platform 1200 of the illustrated example includes aprocessor 1212. The processor 1212 of the illustrated example ishardware. For example, the processor 1212 can be implemented by one ormore integrated circuits, logic circuits, microprocessors, GPUs, DSPs,or controllers from any desired family or manufacturer. The hardwareprocessor may be a semiconductor based (e.g., silicon based) device. Inthis example, the processor implements the example data smoother 708,the example data segmenter 712, the example power spectrum generator716, the example data augmenter 720 and/or, more generally, the exampleacceleration data controller 612 of FIGS. 6 and/or 7, the example testcontroller 608, the example acceleration data controller 612, theexample tread depth determiner 618, the example model generator 624, theexample model provider 628, and/or, more generally, the example treaddepth model controller 104 of FIGS. 1, 6, and/or 7.

The processor 1212 of the illustrated example includes a local memory1213 (e.g., a cache). The processor 1212 of the illustrated example isin communication with a main memory including a volatile memory 1214 anda non-volatile memory 1216 via a bus 1218. The volatile memory 1214 maybe implemented by Synchronous Dynamic Random Access Memory (SDRAM),Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random AccessMemory (RDRAM®) and/or any other type of random access memory device.The non-volatile memory 1216 may be implemented by flash memory and/orany other desired type of memory device. Access to the main memory 1214,1216 is controlled by a memory controller.

The processor platform 1200 of the illustrated example also includes aninterface circuit 1220. The interface circuit 1220 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), a Bluetooth® interface, a NFC interface, avehicle bus including a CAN bus, and/or a PCI express interface. In theexample of FIG. 12, the example interface circuit 1220 can implement theexample first input interfaces 604 and the example accelerometerinterface 704.

In the illustrated example, one or more input devices 1222 are connectedto the interface circuit 1220. The input device(s) 1222 permit(s) a userto enter data and/or commands into the processor 1212. The inputdevice(s) can be implemented by, for example, an audio sensor, amicrophone, a camera (still or video), a keyboard, a button, a mouse, atouchscreen, a track-pad, a trackball, isopoint and/or a voicerecognition system.

One or more output devices 1224 are also connected to the interfacecircuit 1220 of the illustrated example. The output devices 1224 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay (LCD), a cathode ray tube display (CRT), an in-place switching(IPS) display, a touchscreen, etc.), a tactile output device, a printerand/or speaker. The interface circuit 1220 of the illustrated example,thus, typically includes a graphics driver card, a graphics driver chipand/or a graphics driver processor.

The interface circuit 1220 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem, a residential gateway, a wireless access point, and/or a networkinterface to facilitate exchange of data with external machines (e.g.,computing devices of any kind) via a network 1226. The communication canbe via, for example, an Ethernet connection, a digital subscriber line(DSL) connection, a telephone line connection, a coaxial cable system, asatellite system, a line-of-site wireless system, a cellular telephonesystem, etc. The network 1226 can implement the network 116 of FIGS. 1,6, and 8.

The processor platform 1200 of the illustrated example also includes oneor more mass storage devices 1228 for storing software and/or data.Examples of such mass storage devices 1228 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, redundantarray of independent disks (RAID) systems, and digital versatile disk(DVD) drives.

The machine executable instructions 1232 of FIGS. 9, 10, and/or 11 maybe stored in the mass storage device 1228, in the volatile memory 1214,in the non-volatile memory 1216, and/or on a removable non-transitorycomputer readable storage medium such as a CD or DVD. In the example ofFIG. 12, the mass storage device 1228, the volatile memory 1214, thenon-volatile memory 1216, and/or the removable non-transitory computerreadable storage medium such as a CD or DVD can implement the controllerdatastore 620 of FIG. 6

FIG. 13 is a block diagram of an example processor platform 1300structured to execute the instructions of FIGS. 9 and/or 11 to implementthe on-board diagnostic module 102 of FIGS. 1, 7, and/or 8. Theprocessor platform 1300 can be, for example, a server, a personalcomputer, a workstation, a self-learning machine (e.g., a neuralnetwork), a mobile device (e.g., a cell phone, a smart phone, a tabletsuch as an iPad™), a personal PDA, an Internet appliance, a DVD player,a CD player, a digital video recorder, a Blu-ray player, a gamingconsole, a personal video recorder, a set top box, a headset or otherwearable device, an ECU, or any other type of computing device.

The processor platform 1300 of the illustrated example includes aprocessor 1312. The processor 1312 of the illustrated example ishardware. For example, the processor 1312 can be implemented by one ormore integrated circuits, logic circuits, microprocessors, GPUs, DSPs,or controllers from any desired family or manufacturer. The hardwareprocessor may be a semiconductor based (e.g., silicon based) device. Inthis example, the processor implements the example data smoother 708,the example data segmenter 712, the example power spectrum generator716, the example data augmenter 720 and/or, more generally, the exampleacceleration data controller 612 of FIGS. 7 and/or 8, the example statuscontroller 808, the example output handler 816, and/or, more generally,the example on-board diagnostic module 102 of FIGS. 1, 7, and/or 8.

The processor 1312 of the illustrated example includes a local memory1313 (e.g., a cache). The processor 1312 of the illustrated example isin communication with a main memory including a volatile memory 1314 anda non-volatile memory 1316 via a bus 1318. The volatile memory 1314 maybe implemented by SDRAM, DRAM, RDRAM® and/or any other type of randomaccess memory device. The non-volatile memory 1316 may be implemented byflash memory and/or any other desired type of memory device. Access tothe main memory 1314, 1316 is controlled by a memory controller.

The processor platform 1300 of the illustrated example also includes aninterface circuit 1320. The interface circuit 1320 may be implemented byany type of interface standard, such as an Ethernet interface, a (USB, aBluetooth® interface, a NFC interface, a vehicle bus (e.g., the vehiclebus 114) including a CAN bus and/or a RF module, and/or a PCI expressinterface. In the example of FIG. 13, the example interface circuit 1320can implement the example second input interfaces 804 and the exampleaccelerometer interface 704.

In the illustrated example, one or more input devices 1322 are connectedto the interface circuit 1320. The input device(s) 1322 permit(s) a userto enter data and/or commands into the processor 1312. The inputdevice(s) can be implemented by, for example, an audio sensor, amicrophone, a camera (still or video), a keyboard, a button, a mouse, atouchscreen, a track-pad, a trackball, isopoint and/or a voicerecognition system.

One or more output devices 1324 are also connected to the interfacecircuit 1320 of the illustrated example. The output devices 1324 can beimplemented, for example, by display devices (e.g., LED, an OLED, a LCD,a CRT, an IPS display, a touchscreen, etc.), a tactile output device, aprinter and/or speaker. The interface circuit 1320 of the illustratedexample, thus, typically includes a graphics driver card, a graphicsdriver chip and/or a graphics driver processor.

The interface circuit 1320 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem, a residential gateway, a wireless access point, and/or a networkinterface to facilitate exchange of data with external machines (e.g.,computing devices of any kind) via a network 1326. The communication canbe via, for example, an Ethernet connection, a (DSL) connection, atelephone line connection, a coaxial cable system, a satellite system, aline-of-site wireless system, a cellular telephone system, etc. Thenetwork 1326 also can implement the network 116 of FIGS. 1, 6, and 8.

The processor platform 1300 of the illustrated example also includes oneor more mass storage devices 1328 for storing software and/or data.Examples of such mass storage devices 1328 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and DVD drives.

The machine executable instructions 1332 of FIGS. 9 and/or 11 may bestored in the mass storage device 1328, in the volatile memory 1314, inthe non-volatile memory 1316, and/or on a removable non-transitorycomputer readable storage medium such as a CD or DVD. In the example ofFIG. 13, the mass storage device 1328, the volatile memory 1314, thenon-volatile memory 1316, and/or the removable non-transitory computerreadable storage medium such as a CD or DVD can implement the localdatastore 812 of FIG. 8.

From the foregoing, it will be appreciated that example methods,apparatus and articles of manufacture have been disclosed that can traina tread depth status model and implement the tread depth status model todetermine a likely tread depth and/or a likely tread depth statusassociated with one or more tires of a vehicle such as the vehicle 100.The disclosed methods, apparatus and articles of manufacture improve theefficiency of using a computing device by using measured tread depthsand/or measured tread depth statuses and acceleration data of a vehicleto train and deploy a tread depth status model to determine a treaddepths and/or tread depth statuses associated with one or more tires ofa vehicle. The disclosed methods, apparatus and articles of manufactureare accordingly directed to one or more improvement(s) in thefunctioning of a computer.

Example 1 includes an apparatus for determining a tread depth status ofa tire of a vehicle, the apparatus comprising an accelerometer interfaceto access acceleration data from an accelerometer associated with thetire, the acceleration data including first acceleration data indicativeof acceleration in a first direction, second acceleration dataindicative of acceleration in a second direction, and third accelerationdata indicative of acceleration in a third direction, a data segmenterto segment the first acceleration data into a first data segment, thesecond acceleration data into a second data segment, and the thirdacceleration data into a third data segment based on at least one of anacceleration cycle or a common time interval, a power spectrum generatorto generate a first power spectrum density associated with the firstdata segment, a second power spectrum density associated with the seconddata segment, and a third power spectrum density associated with thethird data segment, a data augmenter to augment the first, second, andthird power spectrum densities into a fourth power spectrum density, anda status controller to determine the tread depth status based on thefourth power spectrum density.

Example 2 includes the apparatus of example 1, further including anoutput handler to provide the tread depth status to a display of thevehicle.

Example 3 includes the apparatus of example 1, wherein the datasegmenter is to segment the first, second, and third acceleration datainto first, second, and third data segments based on the accelerationcycle, the acceleration cycle associated with a revolution of the tireincluding a contact event of the accelerometer.

Example 4 includes the apparatus of example 3, wherein the accelerationcycle is an aggregation based on two or more acceleration cycles.

Example 5 includes the apparatus of example 1, wherein the accelerometerinterface, the data segmenter, the data augmenter, the power spectrumgenerator, and the status controller are implemented by an electroniccontrol unit of the vehicle.

Example 6 includes the apparatus of example 1, wherein the tread depthstatus is indicative that a tread depth of the tire is above or below athreshold.

Example 7 includes the apparatus of example 1, wherein the tread depthstatus is indicative that a tread depth of the tire is within a range oftread depths.

Example 8 includes a method for determining a tread depth status of atire of a vehicle, the method comprising accessing acceleration datafrom an accelerometer associated with the tire, the acceleration dataincluding first acceleration data indicative of acceleration in a firstdirection, second acceleration data indicative of acceleration in asecond direction, and third acceleration data indicative of accelerationin a third direction, segmenting the first acceleration data into afirst data segment, the second acceleration data into a second datasegment, and the third acceleration data into a third data segment basedon at least one of an acceleration cycle or a common time interval,generating a first statistic associated with the first data segment, asecond statistic associated with the second data segment, and a thirdstatistic value associated with the third data segment, augmenting thefirst statistic, second statistic, and third statistic into a fourthstatistic, determining the tread depth status based on the fourthstatistic.

Example 9 includes the method of example 8, further including providingthe tread depth status to a display of a vehicle.

Example 10 includes the method of example 8, wherein segmenting thefirst, second, and third acceleration data into first, second, and thirddata segments is based on the acceleration cycle, the acceleration cycleassociated with a contact event of the accelerometer.

Example 11 includes the method of example 10, wherein the accelerationcycle is based on an aggregation of two or more acceleration cycles.

Example 12 includes the method of example 8, wherein determining thetread depth status is at least partially achieved by an electroniccontrol unit of the vehicle.

Example 13 includes the method of example 8, wherein the tread depthstatus is indicative that a tread depth of the tire is above or below athreshold.

Example 14 includes the method of example 8, wherein the tread depthstatus is indicative that a tread depth of the tire is within a range oftread depths.

Example 15 includes the method of example 8, wherein the fourthstatistic is a power spectrum density.

Example 16 includes an electronic control unit (ECU) for determining atread depth of a tire of a vehicle, the ECU comprising an inputinterface to access acceleration data from an accelerometer associatedwith the tire, the acceleration data including first acceleration dataindicative of acceleration in a first direction, second accelerationdata indicative of acceleration in a second direction, and thirdacceleration data indicative of acceleration data in a third direction,a data segmenter to segment at least the first acceleration data into afirst data segment, the second acceleration data into a second datasegment, and the third acceleration data into a third data segment basedon at least one of an acceleration cycle or a common time interval, apower spectrum generator to generate a first power spectrum densityassociated with the first data segment, a second power spectrum densityassociated with the second data segment, and a third power spectrumdensity associated with the third data segment, a data augmenter toaugment the first, second, and third power spectrum densities into afourth power spectrum density, and a status controller to determine thetread depth based on the fourth power spectrum density.

Example 17 includes the ECU of example 16, wherein the tread depth isindicative of a numerical tread depth of the tire.

Example 18 includes the ECU of example 17, further including an outputhandler to provide at least one of the tread depth or a tread depthstatus to a display of a vehicle.

Example 19 includes the ECU of example 16, wherein the fourth powerspectrum density is a matrix including the first, second, and thirdpower spectrum densities.

Example 20 includes the ECU of example 16, wherein the status controlleris to determine the tread depth based on a regression.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

The following claims are hereby incorporated into this DetailedDescription by this reference, with each claim standing on its own as aseparate embodiment of the present disclosure.

What is claimed is:
 1. An apparatus for determining a tread depth statusof a tire of a vehicle, the apparatus comprising: an accelerometerinterface to access acceleration data from an accelerometer associatedwith the tire, the acceleration data including first acceleration dataindicative of acceleration in a first direction, second accelerationdata indicative of acceleration in a second direction, and thirdacceleration data indicative of acceleration in a third direction; adata segmenter to segment the first acceleration data into a first datasegment, the second acceleration data into a second data segment, andthe third acceleration data into a third data segment based on at leastone of an acceleration cycle or a common time interval; a power spectrumgenerator to generate a first power spectrum density associated with thefirst data segment, a second power spectrum density associated with thesecond data segment, and a third power spectrum density associated withthe third data segment; a data augmenter to augment the first, second,and third power spectrum densities into a fourth power spectrum density;and a status controller to determine the tread depth status based on thefourth power spectrum density.
 2. The apparatus of claim 1, furtherincluding an output handler to provide the tread depth status to adisplay of the vehicle.
 3. The apparatus of claim 1, wherein the datasegmenter is to segment the first, second, and third acceleration datainto first, second, and third data segments based on the accelerationcycle, the acceleration cycle associated with a revolution of the tireincluding a contact event of the accelerometer.
 4. The apparatus ofclaim 3, wherein the acceleration cycle is an aggregation based on twoor more acceleration cycles.
 5. The apparatus of claim 1, wherein theaccelerometer interface, the data segmenter, the data augmenter, thepower spectrum generator, and the status controller are implemented byan electronic control unit of the vehicle.
 6. The apparatus of claim 1,wherein the tread depth status is indicative that a tread depth of thetire is above or below a threshold.
 7. The apparatus of claim 1, whereinthe tread depth status is indicative that a tread depth of the tire iswithin a range of tread depths.
 8. A method for determining a treaddepth status of a tire of a vehicle, the method comprising: accessingacceleration data from an accelerometer associated with the tire, theacceleration data including first acceleration data indicative ofacceleration in a first direction, second acceleration data indicativeof acceleration in a second direction, and third acceleration dataindicative of acceleration in a third direction; segmenting the firstacceleration data into a first data segment, the second accelerationdata into a second data segment, and the third acceleration data into athird data segment based on at least one of an acceleration cycle or acommon time interval; generating a first statistic associated with thefirst data segment, a second statistic associated with the second datasegment, and a third statistic value associated with the third datasegment; augmenting the first statistic, second statistic, and thirdstatistic into a fourth statistic; determining the tread depth statusbased on the fourth statistic.
 9. The method of claim 8, furtherincluding providing the tread depth status to a display of a vehicle.10. The method of claim 8, wherein segmenting the first, second, andthird acceleration data into first, second, and third data segments isbased on the acceleration cycle, the acceleration cycle associated witha contact event of the accelerometer.
 11. The method of claim 10,wherein the acceleration cycle is based on an aggregation of two or moreacceleration cycles.
 12. The method of claim 8, wherein determining thetread depth status is at least partially achieved by an electroniccontrol unit of the vehicle.
 13. The method of claim 8, wherein thetread depth status is indicative that a tread depth of the tire is aboveor below a threshold.
 14. The method of claim 8, wherein the tread depthstatus is indicative that a tread depth of the tire is within a range oftread depths.
 15. The method of claim 8, wherein the fourth statistic isa power spectrum density.
 16. An electronic control unit (ECU) fordetermining a tread depth of a tire of a vehicle, the ECU comprising: aninput interface to access acceleration data from an accelerometerassociated with the tire, the acceleration data including firstacceleration data indicative of acceleration in a first direction,second acceleration data indicative of acceleration in a seconddirection, and third acceleration data indicative of acceleration datain a third direction; a data segmenter to segment at least the firstacceleration data into a first data segment, the second accelerationdata into a second data segment, and the third acceleration data into athird data segment based on at least one of an acceleration cycle or acommon time interval; a power spectrum generator to generate a firstpower spectrum density associated with the first data segment, a secondpower spectrum density associated with the second data segment, and athird power spectrum density associated with the third data segment; adata augmenter to augment the first, second, and third power spectrumdensities into a fourth power spectrum density; and a status controllerto determine the tread depth based on the fourth power spectrum density.17. The ECU of claim 16, wherein the tread depth is indicative of anumerical tread depth of the tire.
 18. The ECU of claim 17, furtherincluding an output handler to provide at least one of the tread depthor a tread depth status to a display of a vehicle.
 19. The ECU of claim16, wherein the fourth power spectrum density is a matrix including thefirst, second, and third power spectrum densities.
 20. The ECU of claim16, wherein the status controller is to determine the tread depth basedon a regression.